What to do about the CRA, in order

Search for a CRA checklist and you will find flat lists of twenty-five or thirty items, which implies they all matter equally and can be tackled in any order. They cannot. Some items have dependencies on other people's calendars; some are already overdue; most are not due for more than a year. Getting the order right is worth more than getting the list complete.

The three decisions that come first

1. Does the regulation apply to this product?

Three tests, and each one is capable of ending the enquiry: is it placed on the EU market; is it a product rather than a service; and is it supplied in the course of a commercial activity. A pure cloud service is generally out. Unmonetised open source is out. Medical devices, vehicles, aircraft and marine equipment are out because other regimes cover them. The full scope rules, or the two-minute check.

2. Which class is it?

Look your product up against Annex III and Annex IV. Most products are on neither list, which means the default category and self-assessment: no notified body, no external audit, no certification fee, and a timeline you control. If you are on one of those lists the answer changes materially, and for Class II and Annex IV a third party is now in your critical path. How the two lists work.

Do this second, and do it properly. It is the only decision in the whole exercise that can add months rather than days, and the only one where being wrong is expensive rather than correctable.

3. How long will you provide security updates?

The support period must reflect how long the product is expected to be in use, and must be at least five years unless it is expected to be in use for less. Pick the number deliberately, because it propagates:

• It goes in the user information as a date, not a duration.
• It has to be visible at the time of purchase — a separate duty from the manual.
• Its justification is a required part of the technical documentation.
• It extends your retention duties where it runs past ten years.

What a long support period actually commits you to.

This week: the duty that is already live

The reporting obligations in Article 14 have applied since 11 September 2026. Everything else is future work. This is not.

What "being ready" actually means, and none of it takes long:

1. Create the EU Login account for whoever will file, with two-factor enabled, and register on the ENISA single reporting platform. Reports are filed manually, and an account cannot be created inside a 24-hour window.
2. Work out which CSIRT you report to. It follows from where your cybersecurity decisions are predominantly taken, not from where the company is registered. The routing rule, and the trap in it.
3. Name the person who files, and their backup. Write both names down somewhere the on-call person can find them.
4. Pre-draft the reports. Your company details and product identifiers do not change during an incident; fill them in now so the 24-hour window is spent on the incident.
5. Know the four deadlines, and in particular that neither final-report clock starts at discovery. The two tracks, and the clocks people get wrong.

This quarter: the things with lead times

Everything in this section depends on somebody else, which is why it goes before the writing.

Before December 2027: the documents

The substantive obligations apply from 11 December 2027. That is not a grace period in any useful sense — the technical file has to describe a product that was designed to meet Annex I, which is not something you can assemble retrospectively — but it is the date the paperwork is measured against.

Five documents, and the order below is the order that avoids doing work twice:

1. The cybersecurity risk assessment first. It addresses each of the thirteen requirements in Annex I Part I, and its answers feed everything else. With the harmonised standards still in development there is no standard to cite instead, so this document carries more weight in your file than it would under a mature regime.
2. The user information, because seven of its nine points are facts you have already written down. The nine points.
3. The support period justification, which is one or two paragraphs recording the reasoning behind decision three above.
4. The technical documentation, which is largely an index to the other documents plus the architecture description and the test reports. Annex VII, point by point.
5. The declaration of conformity last, because it is the claim the other four support. What signing it commits you to.

Alongside them: generate an SBOM per release from your existing build tooling, and store it with the version of the product it describes. The statutory floor is the top-level dependencies, so this is a command rather than a project. What the CRA actually asks for.

Forever: the duties that recur

The mistake in treating this as a project is that half of it is not one. Annex I Part II is a process, and Article 13 is a filing obligation with a ten-year memory.

• Handle vulnerabilities — identify, remediate without delay, disclose once fixed, ship the update free of charge with an advisory message.
• Test regularly, and be able to say what testing runs and how often.
• Keep the SBOM current per release.
• Re-examine the file after a substantial modification, and keep the previous version, because it is the one that governed the units already sold.
• Watch for the harmonised standards. When a tranche is cited in the Official Journal, your Annex VII point 5 answer changes. The published schedules have already moved once.
• Track each security update's own retention clock. Ten years from each update's issue, which means the last update you ship extends the obligation well past the product's own date.

What can safely wait

Worth saying explicitly, because a flat checklist implies otherwise:

• Waiting for the harmonised standards before starting. They are not due in full until late 2027 and the schedule has slipped once. The risk assessment does not depend on them.
• Buying SBOM tooling. Your package manager already emits one.
• A consultant, if you are in the default category. Self-assessment means nobody outside your company is involved. Get advice on a marginal classification or a genuinely hard question, not on the writing.
• Choosing a document format. The regulation prescribes contents, not forms.
• Worrying about the €15m fine. It is a ceiling on national law, authorities are required to weigh the size of the operator, and for a small manufacturer making a good-faith effort the realistic outcome is an order to remediate.

Why this order, and not a different one

Three dependencies drive it, and they are the reason a flat list produces wasted work:

Classification gates the documentation. Writing a technical file before you know whether a notified body has to examine it risks writing the wrong file, and — more importantly — discovering the lead time late.

The support period propagates. It appears in the user information, at the point of purchase, in the technical documentation and in the retention dates. Changing it after those are written means changing all of them.

Reporting is live and everything else is not. A process you can execute inside 24 hours is worth more this month than a document that is not due for fourteen. It is also the cheaper of the two to get ready.