EU CRA Annex I: where conformity assessment pipelines break before market access
Geert WarmenbolApril 29, 2026
Key takeaways
CRA Annex I requires products to ship with a secure default configuration. In Vulnox assessments, the most common failure is not a missing control but a control that exists in the development build and is absent or weakened in the factory firmware image that actually ships.
The CRA SBOM requirement under Annex I section 1 point 1(e) assumes that the SBOM accurately reflects the software components present in the shipped product. It does not require validation that the SBOM matches the actual firmware binary. That gap is the most exploitable structural weakness in the CRA compliance pipeline.
CRA Article 11 requires manufacturers to handle vulnerabilities without undue delay. The average time to patch a critical vulnerability in embedded systems after public disclosure runs to approximately 182 days in practice, based on Vulnox assessment data. The CRA does not define a maximum remediation window, which creates a specific tension between regulatory intent and embedded system update economics.
Annex II defines important product categories subject to stricter third-party conformity assessment. The classification criteria are technology-based, not risk-based. A consumer smart lock and an industrial gateway controlling physical access to infrastructure can fall into different Annex II categories based on product classification rather than actual attack surface or consequence of compromise.
Automated vulnerability scanners reliably find known CVEs in identifiable software versions. They do not find hardcoded credentials in proprietary firmware, insecure bootloader configurations, or debug interfaces left active in production hardware. CRA Annex I requirements address all of these. Conformity assessment evidence based on scan reports alone leaves the most exploitable gaps undetected.
A prediction: within three years, the first large-scale exploit campaign targeting CRA-compliant products will use a vulnerability class that standard conformity assessment tooling does not detect, specifically insecure firmware update mechanisms that pass SBOM validation while accepting unsigned or weakly authenticated update packages.
TL;DR
CRA Annex I is a well-designed requirement set for the wrong assessment methodology. The essential cybersecurity requirements address real attack surface: default configurations, vulnerability handling, secure update mechanisms, and protection of data at rest and in transit. The conformity assessment process that verifies these requirements is predominantly documentation-based and scanner-assisted. Neither method reaches the shipped firmware binary, the actual factory configuration, or the update chain integrity. The gap between documented compliance and shipped product security is where the exploitable failures live.
The firmware that passed and the one that shipped
A consumer electronics manufacturer preparing for CRA conformity assessment submitted technical documentation for a smart home gateway. The documentation included the software bill of materials for firmware version 2.4.1, a vulnerability scan report showing no critical findings against the identified component versions, hardening documentation showing that the default SSH service had been disabled in the production build, and a vulnerability handling policy meeting the Article 11 requirements. The notified body reviewed the documentation and issued the CE marking. The firmware version that shipped to retail channels three weeks later was 2.4.0. A build pipeline misconfiguration had caused the release automation to package the previous firmware image. Version 2.4.0 had SSH enabled by default, used a hardcoded root credential shared across all devices of that model, and contained a component with a known critical CVE that had been patched in 2.4.1.
The conformity assessment had been accurate for the firmware it assessed. The release pipeline did not verify that the firmware image packaged for production matched the version that had been assessed. CRA Annex I section 1 point 1(a) requires products to be placed on the market without known exploitable vulnerabilities. The requirement applies to the shipped product. The assessment process verified the documented product. These are not the same thing, and nothing in the current conformity assessment framework requires a manufacturer to prove they are.
What CRA Annex I actually requires and where the verification chain breaks
CRA Annex I is divided into two parts. Part I covers essential cybersecurity requirements for products with digital elements. Part II covers vulnerability handling requirements for manufacturers. The requirements in Part I address the product as shipped: it must have no known exploitable vulnerabilities at time of market placement, must have a secure default configuration, must protect data confidentiality and integrity, must minimize its attack surface, must support security updates, and must collect only data necessary for its function. Part II covers the manufacturer''s processes: vulnerability disclosure, handling procedures, update mechanisms, and end-of-life policy.
The conformity assessment pathway for most products is self-assessment by the manufacturer against these requirements, supported by technical documentation. For products falling in Annex II important categories, third-party assessment by a notified body is required. In both cases, the assessment methodology is not specified in detail by the regulation. The technical documentation requirements are specified in Annex VI, which lists what must be included but does not mandate that the documentation be verified against the actual shipped product.
Three verification gaps in this structure produce the most consequential compliance failures.
First, the firmware integrity gap. The conformity assessment reviews documentation and, typically, a test build or representative firmware image. It does not verify that the production firmware image packaged for shipping matches the assessed version. A manufacturer with a mature DevSecOps pipeline and a cryptographic release attestation process closes this gap. A manufacturer without one has a window between assessment and shipment where build configuration errors, last-minute patches, or process failures can produce a shipped product that differs materially from the assessed product.
Second, the SBOM accuracy gap. The SBOM is a list of software components the manufacturer asserts are present in the product. CRA Annex I requires the SBOM to exist and to cover direct dependencies at minimum. It does not require that the SBOM be generated from the actual firmware binary rather than from the build manifest. These can differ when build systems pull transitive dependencies, when vendored code is modified without updating the manifest, or when firmware includes components loaded at runtime rather than at build time. An SBOM generated from a build manifest is an assertion. An SBOM generated by binary analysis of the shipped firmware is a measurement. The conformity assessment accepts both without distinguishing between them.
Third, the hardware debug interface gap. CRA Annex I Part I point 1(d) requires that the attack surface be minimized. JTAG, UART, and similar debug interfaces left active in production hardware are a direct attack surface that automated software scanning does not detect. Hardware analysis is not a standard component of CRA conformity assessment methodology. A manufacturer that correctly disables debug interfaces in production hardware meets this requirement. A manufacturer that ships hardware with active debug interfaces, with a conformity assessment based entirely on software documentation and scanning, has a product that fails Annex I on shipped hardware and passes on documentation.
Example
In Vulnox assessments of embedded products undergoing CRA readiness review, the most consistent gap between the conformity assessment documentation and the actual product was in the default configuration. The documented production build had unnecessary services disabled. The factory reset behavior — what the device defaults to when a user performs a factory restore — reverted to a configuration with services enabled that the production first-boot configuration then disabled. A device that had been factory reset was in the documented non-production state until it completed its first-boot setup sequence. If the first-boot sequence failed, was interrupted, or was bypassed, the device remained in the vulnerable default state. The conformity assessment had reviewed the first-boot hardening procedure and marked the default configuration requirement as met. It had not tested the factory reset path.
The firmware binary analysis gap has a specific tooling dimension. SBOM generation tools in common use — Syft, Trivy, and similar — can operate in two modes: manifest-based, which reads package manager lock files and build configurations, and binary analysis, which extracts component signatures from the compiled firmware. Manifest-based SBOM generation is faster and integrates cleanly into CI/CD pipelines. Binary analysis requires firmware unpacking, filesystem extraction, and signature matching against component databases. For embedded systems using custom build systems or proprietary firmware packaging, binary analysis requires additional tooling investment. The CRA does not specify which method is acceptable. Manufacturers optimizing for conformity assessment efficiency use manifest-based generation. Manufacturers optimizing for accuracy use binary analysis. These produce materially different SBOMs for products with complex build chains.
What CRA readiness assessments find in practice
Assessment base: Vulnox CRA readiness assessments and embedded product security reviews, 2024-2025
Factory reset paths that bypass first-boot hardening
In Vulnox CRA readiness assessments of consumer connected devices, the factory reset behavior was the most common path to a configuration state that failed Annex I Part I point 1(b) secure default configuration requirements. The first-boot configuration hardening was correctly implemented. The factory reset procedure restored the device to a pre-hardening state. The sequence between factory reset and completion of first-boot setup left the device in a vulnerable intermediate configuration. In devices that allowed network connectivity during first-boot setup, this intermediate state was reachable remotely.
CRA Annex I requires a secure default configuration. The default state of a device after factory reset is a configuration state that regulators and notified bodies will assess as the default. A manufacturer whose conformity documentation addresses the post-first-boot-setup state but not the post-factory-reset state has documented compliance with a product state that is not the default under the regulation''s intent.
SBOM component counts that do not match binary analysis
In Vulnox binary analysis of firmware images from products with existing manifest-based SBOMs, the component count from binary analysis routinely exceeded the manifest-based SBOM. The gap was consistently largest in products using build systems that vendor dependencies at build time, products with runtime-loaded components not captured in the static build manifest, and products built on top of commercial embedded operating systems where the OS vendor''s component manifest was taken at face value rather than verified. The additional components identified in binary analysis included versions with known CVEs that were not present in the manifest-based SBOM and therefore not assessed in the vulnerability scan.
A vulnerability scan run against a manifest-based SBOM finds vulnerabilities in the components the manufacturer believes are present. It does not find vulnerabilities in components that are present but not in the manifest. The CRA requires products to ship without known exploitable vulnerabilities. A vulnerability that exists in the shipped firmware and is absent from the SBOM is a known vulnerability that the assessment process did not reach.
Active debug interfaces in production hardware
In Vulnox hardware assessments of products that had completed software-only conformity review, JTAG interfaces were accessible on a significant proportion of production units. In most cases the interface was not documented as disabled in the technical documentation because it had not been considered part of the software-defined attack surface that the conformity assessment covered. In several cases the JTAG interface provided unauthenticated access to memory contents including stored credentials and encryption keys.
CRA Annex I Part I point 1(d) requires attack surface minimization. A JTAG interface providing unauthenticated memory access on a production device is an unminimized attack surface regardless of how complete the software-layer conformity assessment documentation is. The gap between software conformity assessment and hardware security is structural in the current methodology, not incidental.
Vulnerability handling timelines exceeding implicit CRA expectations
CRA Article 11 requires manufacturers to address vulnerabilities without undue delay. It does not define a maximum remediation window. In Vulnox assessments of manufacturers'' vulnerability handling processes, the average time from public CVE disclosure for a component in the product to a firmware update being available to end users was approximately 182 days. This figure reflects two delays: the time for the manufacturer to identify the affected component in their product (often delayed when the SBOM is manifest-based and incomplete), and the time to build, test, and distribute a firmware update through whatever update mechanism the product supports.
182 days is not a regulatory violation under the current CRA text because no maximum window is defined. It is a predictable target for attackers who monitor CVE disclosures against known product component lists. A product that patches in 182 days has a 182-day window during which a known vulnerability is exploitable in shipped products. The CRA''s intent in requiring timely handling is not satisfied by a process that consistently delivers updates six months after disclosure.
Annex II classification increases documentation burden without increasing security scrutiny
Common belief
Products classified as important under CRA Annex II face stricter conformity assessment because they are higher-risk products requiring more rigorous security validation. Third-party assessment by a notified body provides a meaningfully higher assurance level than self-assessment.
What we found
In Vulnox assessments of products that had obtained Annex II third-party conformity certification, the firmware binary analysis finding rate for undocumented components with known CVEs was not materially lower than for products that had undergone self-assessment. The notified body assessment had added legitimate third-party review of the documentation. It had not added verification that the documentation matched the binary.
The Annex II classification system is technology-based, not risk-based. A product appears in Annex II based on what it is — an identity management product, a network management product, a browser — not based on a risk assessment of what its compromise would enable. Products with significant real-world attack surface consequences can fall outside Annex II based on classification criteria that do not consider operational context.
The more specific problem is what third-party assessment by a notified body adds in practice. The notified body reviews technical documentation and, depending on the body and the product, may conduct or commission testing. The assessment methodology is not standardized across notified bodies. A manufacturer that engages a notified body whose methodology is primarily documentation review gains CE marking with higher regulatory legitimacy but not necessarily higher assurance that the shipped product matches the documented product.
The structural issue is that the notified body model, inherited from the CE marking framework, was designed for physical product safety. The verification methodology for physical product safety works because the product you test is the product you ship. Firmware can be changed between assessment and shipment without the product changing physically. Third-party assessment for software security needs a firmware attestation mechanism to close the gap. The current CRA framework does not mandate one.
Where CRA conformity assessment consistently misses the shipped product
Bootloader security and secure boot configuration
CRA Annex I Part I point 1(f) requires products to protect the integrity of the software they run. Secure boot is the primary mechanism for this in embedded systems. The conformity assessment documentation typically includes a statement that secure boot is enabled. It does not typically include verification that the secure boot implementation correctly validates the entire boot chain, that the root of trust is appropriately protected, or that the implementation is not vulnerable to known secure boot bypass techniques. Secure boot configuration errors that bypass the entire chain are not visible to software-layer scanning.
Update mechanism authenticity verification
CRA Annex I Part I point 1(g) requires products to receive security updates without undue delay. The mechanism by which updates are delivered and installed is not specified. Many embedded products use update mechanisms that verify update package authenticity with weak signature schemes or no signature verification at all. An update mechanism that accepts unsigned firmware packages satisfies the update delivery requirement and fails the integrity requirement simultaneously. These two requirements are in the same annex section and are frequently assessed separately.
Third-party component license and provenance
The SBOM requirement in Annex I addresses component identity for vulnerability tracking purposes. It does not address component provenance — whether the component was obtained from an authenticated source and has not been modified. Supply chain injection attacks that replace a legitimate component with a trojanized version at build time produce a product with an accurate SBOM that does not reflect the actual software present. Build pipeline integrity, dependency pinning to verified hashes, and authenticated build artifact storage are the controls that close this gap. They are not assessed in current conformity review methodology.
Network service enumeration on factory-reset devices
As described in assessment findings, the factory reset path often produces a different network service profile than the post-first-boot-setup configuration. Conformity assessments that test the hardened post-setup state and document it as the default miss the exploitable intermediate state. A full conformity assessment of secure default configuration should enumerate listening services and open ports on a freshly factory-reset device before first-boot setup has been completed.
End-of-life security update obligations
CRA Article 13(8) requires manufacturers to specify the support period for security updates and to inform purchasers. The end-of-life date is documented in the technical documentation. What is not typically assessed is whether the manufacturer has a viable mechanism to deliver security updates throughout the stated support period, and whether the update mechanism remains functional on devices that have been in deployment for the full support period without connectivity interruptions. A five-year stated support period that the update mechanism cannot fulfill in practice is a documentation commitment without operational backing.
The numbers behind embedded product compliance failures
The average time from CVE public disclosure to available firmware patch for embedded products in Vulnox assessments was approximately 182 days
This figure includes both the time to identify the affected component and the time to build and distribute the update. For products with manifest-based SBOMs that do not reflect all shipped components, the identification step alone can consume weeks when the vulnerability disclosure does not include the exact package name present in the build system. Source: Vulnox CRA readiness assessment data, 2024-2025.
Binary analysis of firmware images in Vulnox CRA assessments consistently produced SBOM component counts exceeding manifest-based SBOMs, with the gap largest in products using vendored dependencies or commercial embedded OS layers
The additional components identified in binary analysis included versions with known CVEs not present in the manufacturer''s existing vulnerability tracking process. These components were compliant with the CRA SBOM requirement under a manifest-based interpretation and non-compliant under a binary-accuracy interpretation. Source: Vulnox firmware analysis engagements, 2024-2025.
CRA enforcement begins in December 2027 for products with digital elements, with earlier application dates for specific categories and the vulnerability handling and reporting requirements applying from September 2026
Manufacturers of products with longer development cycles who have not begun CRA conformity preparation are already building products that will need to demonstrate compliance against requirements that are in force before the product reaches market. Source: EU Cyber Resilience Act Article 71.
Where CRA enforcement and exploitation patterns are heading
Within three years of CRA enforcement beginning, the first large-scale exploit campaign targeting CRA-compliant products will use unsigned or weakly authenticated firmware update mechanisms as the attack vector, demonstrating that update delivery compliance and update integrity assurance are different requirements that the conformity assessment process did not separate.
Firmware update mechanisms are the highest-value target in the connected product attack surface: code execution with full device privileges, persistence across reboots, and propagation to every device with the same update infrastructure. The CRA requires update mechanisms to exist and to deliver patches without undue delay. It does not mandate update package signature schemes or specify minimum signature verification requirements. Manufacturers optimizing for conformity assessment compliance build update mechanisms that deliver updates. Manufacturers optimizing for security build update mechanisms that verify what they deliver. These are not the same population, and the exploit will find the first population.
Confidence: highAbsence of any publicly attributed large-scale campaign exploiting CRA-compliant product update mechanisms by end of 2030. Observable leading signal: ENISA or national cybersecurity authority advisories in 2027-2028 identifying firmware update mechanism integrity as a gap in first-wave CRA implementations.The European Commission will publish interpretive guidance or amend the CRA delegated acts by end of 2027 to require firmware binary attestation as part of conformity assessment evidence for Annex II products, in response to documented cases where shipped firmware differed from assessed firmware.
The firmware attestation gap is structural and will produce documented compliance failures once enforcement is active. The Commission has a track record of amending technical annexes and publishing interpretive guidance in response to identified implementation failures in other product regulation regimes, notably the Medical Device Regulation. The Annex II pathway already mandates third-party assessment; adding a firmware attestation requirement to that pathway is a targeted extension of existing infrastructure rather than a new mechanism.
Confidence: mediumNo Commission guidance or delegated act amendment requiring firmware attestation for Annex II products by end of 2027. Observable leading signal: notified body technical guidance documents in 2026 that begin requiring manufacturers to provide build reproducibility evidence alongside conformity documentation.
What manufacturers say going in, and what the binary shows
We have MFA on all developer accounts and a documented SBOM. The access control and software composition requirements are covered.
Root cause:Developer account MFA addresses the build pipeline access control, not the product authentication requirements under Annex I. The SBOM addresses the component documentation requirement. Neither addresses whether the shipped firmware binary matches the documented components, whether the product itself enforces authentication on its network interfaces, or whether the SBOM was generated from the build manifest or from binary analysis. All three are separate requirements. Implementing two and documenting them does not cover the third.
Our vulnerability scanner shows no critical findings. The vulnerability management requirement is met.
Root cause:A vulnerability scanner running against identifiable software versions finds known CVEs in those versions. It does not find hardcoded credentials in proprietary firmware components that do not have CVE identifiers, it does not find debug interfaces enabled in production hardware, and it does not find components in the shipped binary that are not in the SBOM used as the scan target. The scanner is accurate for what it scans. The question is whether what it scanned is the complete attack surface the CRA requires to be assessed.
We obtained third-party conformity certification from a notified body for our Annex II product. Our compliance is validated.
Root cause:Notified body certification validates that the technical documentation submitted for assessment meets the Annex I and II requirements as documented. It does not validate that the firmware image packaged for production after assessment matches the assessed version. The certification is accurate for the product assessed. Release pipeline controls that ensure the assessed and shipped firmware are identical are the manufacturer''s responsibility and are not part of the notified body''s scope.
What the CRA gets right and where the implementation will fail predictably
The CRA is the most technically specific product security regulation the EU has produced. The Annex I requirements — no known exploitable vulnerabilities at market placement, secure default configuration, minimal attack surface, authenticated update mechanisms, SBOM — are the right requirements. They address the actual attack surface of connected products in a way that previous EU product regulations did not.
The conformity assessment methodology is not adequate for these requirements. It was designed for physical product safety, where you test the thing and the thing you test is the thing you ship. Software does not work that way. The assessment framework needs a firmware attestation mechanism: a cryptographically verifiable binding between the firmware binary that was assessed and the firmware binary that was packaged for production. Without it, the gap between assessed and shipped product is invisible to the compliance process and visible to anyone who looks at the release pipeline.
My prediction, stated clearly: the first wave of CRA-compliant products will produce a documented exploitation case within three years of enforcement beginning, using a vulnerability class that the conformity assessment methodology does not reach. That case will be used to justify exactly the kind of binary attestation requirement the regulation should have included in the first version. The regulatory response will be correct. The sequence — requirement, implementation gap, exploitation, amendment — will be predictable in retrospect and was avoidable.
Manufacturers who build binary attestation into their release pipelines now, before it is mandated, will have a compliance artifact that the next version of the regulation requires. They will also have a product that is more difficult to exploit in the gap period.
Counterargument
The counterargument is that binary attestation requirements would significantly increase conformity assessment costs for smaller manufacturers, creating market access barriers that disadvantage European connected product companies against competitors from markets with less stringent requirements. This is a real tension in EU product regulation design. The response is that the alternative — a regulation that appears rigorous and produces CRA-compliant products with known firmware attestation gaps — creates a different market access problem: products that fail publicly after certification, which damages the CE marking''s market signal more broadly than a higher compliance bar would.
One thing to do before the end of the week
Take the firmware image that will be packaged for your next production release and compute its cryptographic hash. Compare it to the hash of the firmware image that was used for your most recent conformity assessment or security review. If they are different, trace which build produced each and document why they differ.
This takes thirty minutes. It is not a full binary analysis. It is the first question in a firmware attestation process, and it will tell you whether the gap between your assessed product and your shipped product exists. If it does, you now know before a regulator or a researcher does.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
comprehensive vulnerability assessmentNational Vulnerability Database NIST
NIST National Vulnerability DatabaseNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
What does CRA Annex I require for default configuration of connected products?
CRA Annex I Part I point 1(b) requires products to be placed on the market with a secure default configuration. In practice, this means no unnecessary network services running at first boot, no shared or hardcoded credentials, and attack surface minimized before any user configuration. A common failure mode in Vulnox assessments is products that implement first-boot hardening correctly but revert to a vulnerable intermediate configuration after factory reset, which regulators assess as the default state.
What is the SBOM requirement under CRA Annex I and what does it actually require?
CRA Annex I requires manufacturers to produce a software bill of materials covering at minimum the top-level dependencies of the product. The regulation does not specify whether the SBOM must be generated from the build manifest or from binary analysis of the shipped firmware. These produce materially different results for products with complex build chains. Manifest-based SBOMs are faster to generate and miss components loaded at runtime, vendored dependencies not tracked in the manifest, and components present in commercial embedded OS layers.
What is the difference between CRA self-assessment and Annex II third-party conformity assessment?
Most products undergo self-assessment by the manufacturer against Annex I requirements. Products classified as important under Annex II require third-party assessment by a notified body. Third-party assessment adds review of technical documentation by an external body. It does not mandate a different assessment methodology for the firmware binary itself. In Vulnox assessments, the rate of undocumented components with known CVEs found through binary analysis was not materially lower for Annex II third-party certified products than for self-assessed products.
How does CRA Article 11 define timely vulnerability handling for embedded products?
CRA Article 11 requires manufacturers to address vulnerabilities in their products without undue delay but does not define a maximum remediation window. In Vulnox assessment data, the average time from CVE public disclosure to available firmware patch for embedded products was approximately 182 days. This timeline reflects both the delay in identifying affected components and the time to build and distribute the update. Products with incomplete SBOMs have longer identification delays because CVE disclosures cannot be automatically matched to product components.
What hardware attack surfaces does CRA Annex I address that software scanning misses?
CRA Annex I Part I point 1(d) requires attack surface minimization. JTAG, UART, and similar debug interfaces left active in production hardware are a direct attack surface that automated software scanning does not detect. In Vulnox hardware assessments of products with complete software-layer conformity documentation, active JTAG interfaces were found on a significant proportion of production units. These interfaces in several cases provided unauthenticated memory access including stored credentials. Hardware security review is not a standard component of current CRA conformity assessment methodology.
When does CRA enforcement begin and which requirements apply first?
CRA vulnerability handling and reporting requirements under Article 14 apply from September 2026. Full enforcement for products with digital elements begins in December 2027. Products in development now with longer release cycles will reach market under active enforcement. Manufacturers building products today that plan to ship in 2026 or later should be incorporating Annex I requirements into the product development process now, particularly around default configuration, SBOM generation methodology, and update mechanism authentication, which are the requirements with the longest remediation lead times.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.