The rest of the EU Cyber Resiliency Act lands on December 11th, 2027.

As of mid-August 2026, the number of Cyber Resilience Act harmonized standards published in the Official Journal is zero. Not "a handful" — zero. The Article 27 presumption of conformity is therefore not available for every product category, and the NANDO database lists no CRA-designated notified bodies, so you couldn't book a third-party assessment today, even if you wanted one.

December 11th, 2027 does not move on that account. That is roughly sixteen months away, and on that date the whole regulation applies: the Annex I essential requirements, the Article 13 manufacturer obligations, conformity assessment, CE marking, technical documentation.

The temptation is to wait for the standards to land and then work backward. That's the wrong read. CRA obligations apply on the regulation's own timeline whether or not a standard exists — you are permitted to meet Annex I directly and record in your technical documentation how you did it. What you cannot do is retroactively generate sixteen months of evidence in the final quarter.

We covered the September 11th, 2026 reporting deadline in a separate post. This one is about the other, larger half.

What actually lands in December 2027

Annex I has two parts, and they behave differently. Part I sets the security properties the product must have, assessed at the point you place it on the market. Part II sets the vulnerability-handling processes you must be running, assessed at any point across the support period.

The practical relationship runs the other way from the dates. A functioning Part II process — SBOMs, triage, disclosure — is what makes the September reporting obligation survivable. Most teams will build Part II to serve Article 14 and then discover they've done two-thirds of the December 2027 work.

Classification decides how much of this hurts

Your conformity route depends on which tier your product sits in, and the guidance is firm that tier is decided by core functionality — the features without which the product could not meet its intended purpose. Every product has exactly one, and it belongs in your technical documentation.

Two notable clarifications. Integration is not classification: a router that integrates a firewall component is still a router, and a smartphone that ships an operating system does not have an operating system's core functionality. And you cannot classify by press release — the guidance closes off using inconsistencies between marketing material, instructions and technical documentation to reach the milder regime.

Then the routes:

• Default category — self-assessment.
• Important, Class I — self-assessment by internal control (module A) is available only where a harmonised standard is applied in full and covers all risks of the core functionality. No standard is published, so that route is not open yet.
• Important, Class II, and critical — third-party assessment, always. A harmonised standard does not unlock self-assessment here.
• FOSS exception — Class I and II products placed on the market as free and open source software may follow the default-category procedures, under Article 32(5).

One rule deserves its own paragraph, because it turns a commercial decision into a regulatory one: modules of a suite that are also marketed separately are classified individually. The guidance works an example where a security suite's SIEM, intrusion detection and analytics modules land in three different tiers. Your pricing page is now a regulatory document. The technical descriptions of each category live in Implementing Regulation (EU) 2025/2392.

The bar is "no known exploitable vulnerabilities" — and "known" includes what your own tools find

Annex I Part I requires products to be placed on the market without known exploitable vulnerabilities. Two words do all the work there, and the guidance defines the first one broadly.

A vulnerability is known when it is listed in a relevant public database such as the EUVD, when it reaches you through coordinated disclosure, when it is prominently reported in reliable media, or when you find it through your own testing — including AI-powered analysis. A short verification period is permissible. The guidance also expects a documented, risk-based release decision where a vulnerability turns up shortly before shipping, weighing a fix-before-release against the risk of delaying a release that closes other holes.

Read that together and the incentive structure is awkward: testing harder generates obligations a more reticent competitor doesn't have. The answer is not to test less. It's that a finding you cannot confidently classify becomes a release decision you cannot defend — so precision is the whole game.

Which brings us to the second word. "Exploitable" is not "present in a dependency," and that gap is where most CRA remediation budget will be won or lost. Endor Labs SCA changes the unit of analysis from dependencies to functions, tracing whether vulnerable code is actually callable across direct, transitive, and phantom dependencies, which reduces findings by an average of 92%. Container Reachability extends the same analysis across the runtime and OS layers and cuts container noise by up to 90% — which is relevant because the CRA does not care which layer of your artifact a vulnerability lives in.

For first-party code, Endor Labs AI SAST orchestrates detection, triage, and remediation agents over a semantic code model. In our June 2026 benchmark across eight real-world projects, it found 192 real vulnerabilities — around 3x what frontier models found — with 4x more high-severity findings than the strongest traditional tool (72 vs 17) and roughly 60% fewer false positives, each with a written classification rationale. If your own AI-assisted findings now count as knowledge, the rationale is the artifact that makes the release decision defensible.

Part II is a process you run, not a document you file

Eight obligations are set out in Annex I, Part II. Four of them land squarely on engineering:

An SBOM in a commonly used machine-readable format that covers at least the top-level dependencies. "At least" is a floor, not a ceiling, and the floor is in the wrong place — as J.P. Morgan highlighted, citing Endor Labs research, roughly 95% of vulnerabilities sit in transitive dependencies. Manifest-based tooling also misses phantom dependencies entirely. Generate per build, not per release, in CycloneDX or SPDX, with VEX annotations attached.

Address and remediate vulnerabilities without delay. There's no fixed day count here; the standard is proportionality to severity and exploitability. This is where Upgrade Impact Analysis and backported patches earn their place — you can see what an upgrade breaks before committing, and close transitive vulnerabilities that aren't in your direct control when a full upgrade doesn't fit.

Effective and regular security tests and reviews. The guidance treats this as adapting reviews to new inputs, not mechanically repeating the same tests. In practice, build testing into CI; an annual pentest alone is not "regular."

Public disclosure of fixed vulnerabilities, with a narrow carve-out where the risks of publishing outweigh the benefits until users can patch. CSAF is the sensible format.

The remaining four are a coordinated vulnerability disclosure policy, a public contact address for vulnerability reports (a security.txt under RFC 9116 does the job), a secure and signed update distribution mechanism, and updates that are free of charge and — where technically feasible — delivered separately from feature updates.

Two Article 13 duties wrap around all of it. Article 13(5) requires due diligence on integrated third-party components: you define what the component must deliver and verify it in a risk-based way, using the supplier's documentation, conformity evidence, and, where appropriate, your own testing. That is the case for treating package selection as a control point rather than a developer preference — malicious package detection, maintainer and abandonment signals, and AI model provenance all sit here. Article 13(6) requires you to report vulnerabilities upstream to the maintainer of the component you actually integrated, following the maintainer's disclosure process, and to share fixes in a machine-readable, license-compatible form. Check advisories first; there's no obligation to duplicate a known report, or to report to a project that no longer has a maintainer.

The long tail of support that nobody budgets for

The support period must reflect the expected time of use. Five years is a floor, not a default, and the guidance is explicit that a blanket five years is attackable where your product is evidently used longer.

Then the retention obligations. Each security update must remain available for at least 10 years after it is issued, or the remainder of the support period, whichever is longer (Article 13(9)). Technical documentation and the declaration of conformity must remain available to market surveillance authorities for 10 years after placing on the market or for the support period, whichever is longer (Article 31). And the support end date has to be visible at the point of purchase, at least to the month and year, with an end-of-support notification where technically feasible (Article 13(19)).

Article 13(10) offers real relief: you may address vulnerabilities only in the version most recently placed on the market, provided users can upgrade free of charge and at no additional cost. The guidance reads "additional costs" narrowly — mandatory hardware purchases or infrastructure replacement, not ordinary personnel time, testing, or configuration work.

The practical consequence is that you will be patching libraries years after the team that wrote the product has moved to something else. That is the argument for minimal backported patches over version upgrades on long-lived products, and for Endor Labs' 6x faster remediation being a support-period economics question rather than a sprint-velocity one.

Two more reliefs worth claiming. Product families: variants that share architecture, security-relevant design, intended purpose, and risk exposure can share one risk assessment, one documentation set, and one declaration of conformity. Color, form factor, and memory size don't split a family; different interfaces, software stacks,s or update mechanisms do. And for legacy products, paragraph 124 of the guidance says a substantial modification by the original manufacturer to a product placed on the market before December 2027 does not require bringing the whole product into full compliance, unless the modification negatively affects the cybersecurity of the product as a whole — obligations are limited to the modified parts.

Be honest with yourself about that last one. It extends the logic of Article 22(2), which on its face covers third parties modifying someone else's products, to the original manufacturer. Practically, it's the right call, since the alternative deters manufacturers from shipping security updates to installed fleets. Legally, it is the most exposed reading in the document, and the guidance binds neither market surveillance authorities nor courts. If you take that route, document the assessment that got you there.

Fourteen months of homework (or less!)

None of this is legal advice, and your counsel should have the final word on classification. But if you want a list:

• Write one sentence per product: "without function X, this product cannot meet its purpose." Classify X against Annex III and IV and Implementing Regulation 2025/2392 — not your feature list.
• Check whether any module you sell separately can be classified on its own, and make the packaging decision deliberately rather than by accident.
• Find the draft standard for your category and read it. ETSI's EN 304 6xx drafts are free to read, and their inquiries close between mid-September and mid-November 2026 — comments still land via your national standardization body.
• Build the Annex I evidence directly, so a delayed Official Journal citation doesn't become your problem.
• Group variants into families now, so you write one risk assessment instead of nine.
• Get SBOM generation into every build, with transitive and phantom dependencies and VEX attached.
• Stand up the CVD policy, the security contact, and a signed update channel.
• Set a defensible support period, document how you derived it, and publish the end date.
• When a standard does get cited, keep a coverage matrix: the presumption of conformity reaches only as far as the standard, and the Article 13(2) risk assessment stays mandatory regardless.

September 2026 tested whether you could answer a question in 24 hours. December 2027 tests whether you can prove the answer repeatedly for a decade after you ship. The standards will arrive. The evidence won't backfill itself.

If you'd like to see how reachability can improve your findings while there's still time to change the process, request a demo.

Additional resources

• Cyber Resilience Act — legal text, Regulation (EU) 2024/2847
• Commission guidance on the CRA, C(2026) 5252 final
• CRA harmonized standards status tracker
• ETSI CYBER-EUSR open consultation drafts
• CRA Article 13 — Obligations of manufacturers

‍