- Endor Labs reports that no Cyber Resilience Act harmonized standards had been published as of mid-August 2026. The full regulation still applies on December 11, 2027.
- As Endor Labs reads the Commission guidance, a flaw your own tools find, including AI-powered analysis, counts as known. That creates release decisions you must defend.
- Start building evidence now: classify each product, generate software bills of materials per build, set a documented support period, and keep records for ten years.
What you know becomes what you owe
Most compliance deadlines reward the team that waits for the rulebook. The EU Cyber Resilience Act (CRA) does not. Security firm Endor Labs argues that its core test is not a document you file at the end. It is a record of behavior that must exist before you ship, and for years after.
The lesson here is that the CRA turns knowledge into liability. The more your tools find, the more you must be able to explain. Evidence cannot be created after the fact.
Endor Labs published its analysis on October 14, 2026. It reads the European Commission's guidance on the regulation (C(2026) 5252 final) and the legal text, Regulation (EU) 2024/2847. Endor Labs sells security tooling, so treat its product claims as vendor claims. Its reading of the rules is the useful part. It is not legal advice.
The deadline holds, whatever the state of the standards
Endor Labs reports that, as of mid-August 2026, no harmonized standards had been published. Harmonized standards are the agreed technical benchmarks that give a product a presumption of conformity. This report does not say whether any have appeared since.
Endor Labs also says that, as of mid-August 2026, the EU's NANDO database named no notified bodies for the CRA. These are the outside assessors some products will need. On that picture, a third-party assessment could not be booked.
The full regulation still applies on December 11, 2027. That covers the Annex I essential requirements, manufacturer duties under Article 13, conformity assessment, CE marking and technical documentation.
Endor Labs says a missing standard is no excuse to wait. A manufacturer may meet Annex I directly. It must then explain in its technical documentation how it did so. What it cannot do is create months of evidence in the final quarter.
How the rules work: a product and a process
Annex I has two parts. Part I lists the security properties a product must have when it goes on sale. Part II lists the vulnerability-handling work you must keep running for the whole support period.
Endor Labs notes that Part II work also helps with the September 11, 2026 reporting duty, which it covered in a separate post. A working process of software inventories, triage and disclosure does double duty.
Part I requires no known exploitable vulnerabilities at launch. As Endor Labs describes it, the guidance defines "known" broadly. A flaw is known if it is listed in a public database such as the EUVD. It is also known if it arrives through coordinated disclosure or is prominently reported in reliable media. And it is known if your own testing finds it, including AI-powered analysis.
That creates an awkward incentive. Teams that test harder take on duties that a less curious competitor does not. Endor Labs does not advise testing less. A finding you cannot classify with confidence becomes a release decision you cannot defend.
Your pricing page becomes a regulatory document
The guidance says a product's tier is set by its core functionality. That is the feature without which it could not serve its purpose. Each product has one, and it belongs in the technical documentation.
Marketing cannot lower the bar. Endor Labs says you cannot reach a milder regime by pointing to gaps between your sales copy, instructions and technical documents.
Suites face a sharper rule. Modules that are also sold on their own are classified one by one. Endor Labs says the guidance gives an example of a security suite whose three modules fall into three different tiers. The modules are SIEM, intrusion detection and analytics. How you package and price products is now a compliance decision.
The long tail nobody budgets for
The support period must match how long customers will really use the product. Endor Labs says five years is the minimum, not a default. A flat five years can be challenged if the product is clearly used for longer.
Record keeping runs longer still. Each security update must stay available for at least ten years after issue, or for the rest of the support period if that is longer (Article 13(9)).
Article 31 sets a similar rule for paperwork. Authorities must be able to see the technical file and declaration of conformity for ten years after launch, or the support period if longer.
Buyers must also be able to see when support ends. That date must show at the point of sale, at least by month and year (Article 13(19)).
The human cost is plain. Someone will patch libraries in a product years after its original team has moved on. Endor Labs argues this favors small backported fixes over version upgrades on long-lived products.
Where the work lands: the software inventory
Annex I Part II requires a software bill of materials. That is a machine-readable list of components. It must cover at least top-level dependencies. Endor Labs calls that floor too low.
It points to research it says J.P. Morgan highlighted. That research puts roughly 95% of vulnerabilities in transitive dependencies. These are the libraries that your own libraries pull in.
Endor Labs recommends building the inventory with every build, not every release. It also recommends attaching VEX notes, which state whether a flaw actually affects the product.
Article 13(5) adds due diligence on third-party components. Endor Labs argues this makes package choice a control point, not a developer preference.
Questions to put to your team
Ask each product team for a single sentence: "without function X, this product cannot meet its purpose." Then test X against Annex III, Annex IV and Implementing Regulation (EU) 2025/2392. The feature list is the wrong yardstick.
Ask whether any separately sold module would be classified on its own. Ask who decides how AI-assisted findings are triaged and recorded before a release. Ask whether inventories are generated in every build. Ask who owns the support-period calculation and the ten-year record store.
Endor Labs also advises reading the draft ETSI standard for your category. It says the public inquiries close between mid-September and mid-November 2026. Comments go to your national standardization body.
One caution applies to legacy products. Paragraph 124 of the guidance limits duties to the modified parts when the original maker substantially modifies a product sold before December 2027. Endor Labs calls this the most exposed reading in the document. The guidance binds neither authorities nor courts. If you rely on it, document why.
Endor Labs puts the stakes this way: the standards will arrive, but the evidence won't backfill itself.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Endor Labs.
