EU Cyber Resilience Act compliance: what device assessments find that paper audits miss
Amara OkaforApril 29, 2026
Key takeaways
EU Cyber Resilience Act Article 10 requires security testing against 'reasonably foreseeable misuse,' not just intended use -- a scope most manufacturers' QA processes do not cover.
In Vulnox assessments of connected devices, the most common CRA violation is an exposed JTAG or SWD debug interface left active on production firmware, which passes standard functional testing but gives physical attackers full memory read/write access.
CRA Article 11 mandates reporting actively exploited vulnerabilities to national authorities within 24 hours of awareness -- a timeline that is impossible without a pre-built incident detection pipeline tied to deployed device telemetry.
Manufacturers who rely on their component vendors' CE declarations for SBOM completeness are generating incomplete SBOMs. Nested dependencies inside binary blobs from SoC vendors are invisible to automated SBOM tooling and invisible to the manufacturer.
The five-year security update obligation under CRA Article 10(6) is a supply chain problem before it is a development problem -- if the underlying RTOS or SoC SDK goes EOL within the support window, the manufacturer has no upstream patch source.
TL;DR
The EU Cyber Resilience Act is not a documentation exercise. The gap between what the framework requires and what most manufacturers' test programs actually check is wide, specific, and exploitable. Debug interfaces left active in production firmware. SBOMs that miss binary blob dependencies. Incident reporting obligations with no detection pipeline behind them. This article is about where those gaps are, what a hands-on assessment finds, and what manufacturers need to fix before enforcement makes those gaps expensive.
The assumption that produces the wrong answer
A manufacturer of industrial environmental sensors came into a Vulnox assessment with a completed self-declaration of conformity draft, an SBOM generated by their build system, and a security policy that referenced all the right CRA articles. Their internal review had flagged zero critical gaps. The product was three months from its EU launch date. The first thing the assessment found was a live JTAG interface on the production board. The debug header was unpopulated -- no physical pins -- but the interface was electrically active and accessible via test pads. Anyone with a $40 adapter and fifteen minutes could dump the firmware, read credentials stored in flash, and reflash modified code. The device would pass a document review. It failed a hands-on test in under an hour.
The client's assumption was that 'security by default' meant shipping with secure default credentials and disabling remote management interfaces. That is a partial reading of Article 10. The full requirement covers the entire attack surface, including physical interfaces that product teams rarely think of as network-connected -- and that reviewers rarely think to test.
What 'security by design and by default' actually requires from a test perspective
Article 10 of the CRA uses the phrase 'security by design and by default' in a way that sounds familiar to anyone who has read GDPR. The implementation requirement is more demanding than GDPR's equivalent. For connected devices, it means the product must be secure in its default shipped state, with no security-relevant configuration left to the end user unless that configuration choice is explicitly documented and the implications are communicated. It also means the product must be assessed against attack scenarios that go beyond what the product is designed to do. The exact language is 'intended purpose and reasonably foreseeable use, including misuse.' That phrase is doing significant work. A home energy monitor is designed to report consumption data. Reasonably foreseeable misuse includes an attacker using the device as a network pivot point, extracting Wi-Fi credentials from its memory, or spoofing sensor readings to trigger downstream automation. None of those scenarios appear in standard functional QA. Most manufacturers are not testing for them.
Example
In practice, testing for 'reasonably foreseeable misuse' on an embedded device means running firmware extraction attempts via JTAG/SWD, testing for hardcoded credentials in extracted firmware blobs, checking whether the OTA update mechanism validates signatures before flashing, fuzzing the device's network-facing parsers, and testing whether physical tamper events are logged and reported. Standard security checklists do not include all of these. The CRA does not list them explicitly either -- it leaves the scope to the manufacturer's risk assessment. That ambiguity is where most compliance gaps live.
The CRA's conformity assessment paths depend on product class. Class I products can self-declare if they follow a harmonized standard (none yet fully harmonized for CRA). Class II requires third-party assessment. Most manufacturers are defaulting to self-declaration while the harmonized standards are still being developed -- which means the test scope they choose now becomes their documented evidence later.
What hands-on assessments find that documentation reviews miss
Assessment base: Vulnox connected device assessments, 2024-2025, covering manufacturers in industrial IoT, consumer electronics, and building management systems across EU market entrants
Active debug interfaces on production hardware
Across Vulnox assessments of connected devices in scope for CRA compliance, exposed JTAG and SWD interfaces are the single most common finding. The pattern is consistent: development boards have populated debug headers, production boards remove the headers to reduce BOM cost, but the interface remains electrically active and accessible via test pads or unpopulated footprints. Manufacturers document this as 'debug interface disabled' because the header is absent. It is not disabled.
Any attacker with physical access -- a returned device, a device in transit, a device in a semi-public location -- can attach a debug adapter and achieve full read/write access to device memory. Firmware, credentials, cryptographic keys, and any data in flash are exposed. This is a CRA Article 10 violation under 'protection against unauthorized access' and 'confidentiality of stored and transmitted data.' The client in every case was unaware the interface was still live.
SBOM coverage gaps from SoC vendor binary blobs
Automated SBOM generation tools -- SPDX-based or CycloneDX-based -- enumerate software components from build artifacts and package manifests. They cannot enumerate components inside precompiled binary blobs provided by SoC vendors, because those blobs have no manifest. Wi-Fi stack binaries, modem firmware, and proprietary SDKs from chip vendors arrive as opaque binaries with no component-level dependency disclosure. The manufacturer's SBOM shows the blob as a single component. The actual software inside may contain dozens of third-party libraries, some with known CVEs.
A manufacturer presenting an SBOM for CRA compliance is presenting an incomplete picture of their software supply chain. When a CVE is published against a library embedded in a vendor blob, the manufacturer has no automated path to detecting that their device is affected. This is structurally inevitable given current SoC vendor practices, and it is not addressed by any current CRA guidance.
OTA update mechanisms that validate signatures but not rollback conditions
Most manufacturers implementing OTA updates have added signature verification -- the update binary must be signed with the manufacturer's key before the device will accept it. What the assessment consistently finds is that the same mechanism has no rollback protection. A device can be downgraded to an older, vulnerable firmware version using a validly signed old update package. The signature check passes. The device installs a version the manufacturer patched three months ago.
An attacker who obtains a signed older firmware package -- available if the manufacturer ever distributed it -- can push a downgrade to any reachable device. This defeats the security update obligation in CRA Article 10. The manufacturer has a functional patch pipeline and is still running vulnerable firmware on deployed devices. The finding surprises every client because the signature check felt like the complete solution.
Incident reporting pipelines that exist as policy documents only
CRA Article 11 requires notification to national authorities within 24 hours of becoming aware of an actively exploited vulnerability. Every manufacturer assessed had a written incident response policy referencing this obligation. None had a detection mechanism on deployed devices that would generate the awareness the 24-hour clock starts from. Log aggregation from production devices was either absent or collecting data that would not surface an active exploitation event.
The 24-hour obligation is unachievable without deployed device telemetry. A manufacturer who learns about an actively exploited vulnerability from a public disclosure -- rather than from their own detection -- has already missed the notification window by days or weeks. The policy document is compliance theater. The CRA's intent is early notification, which requires early detection.
Encryption does not mean the messages are safe
Common belief
Manufacturers consistently report TLS as the primary evidence that their device's communications are secure. The assumption is: TLS is enabled, traffic is encrypted, the confidentiality requirement is met.
What we found
In Vulnox assessments, the most common TLS misconfiguration is disabled hostname verification in the embedded TLS library configuration -- a single compile-time flag that developers set during development to avoid certificate hassle and forget to reverse before production builds. The device reports TLS enabled. The connection accepts any certificate. The CRA requires protection of data in transit. This does not meet it.
TLS on an embedded device is a protocol, not a guarantee. The guarantee depends on what happens around the protocol. Certificate validation is the first failure point. A significant share of embedded TLS implementations in connected devices accept expired certificates, self-signed certificates without pinning, or skip hostname verification entirely -- because the developer who implemented it was solving a functional problem ('get data to the server') rather than a security problem. The encryption is real. The authentication is absent. A device that encrypts its traffic to any server that presents a certificate is trivially man-in-the-middled. The second failure point is key storage. TLS private keys and certificates stored in unprotected flash regions are extractable via the same JTAG access described above. The encryption protects data in transit. The key is recoverable from the device. The protection is not end-to-end.
Where CRA enforcement pressure lands first
The first wave of CRA enforcement actions will target OTA update mechanism failures, not documentation gaps, because exploited vulnerabilities in deployed devices produce the observable harm that triggers Article 11 reporting obligations -- and the reporting failure is directly auditable.
National market surveillance authorities under the CRA have the power to require withdrawal of products from the market. The trigger is a product that presents an unacceptable risk. An exploited vulnerability in a device with a broken OTA mechanism -- one that cannot receive or verify patches -- is a cleaner enforcement case than a missing policy document. Regulators follow the evidence trail. The evidence trail for software exploitation is more concrete than for documentation review.
Confidence: mediumFirst three CRA enforcement actions published by EU national market surveillance authorities by end of 2027 -- if the majority cite OTA or patch mechanism failures, this prediction holds. If they primarily cite documentation gaps, it does not.SoC vendor binary blob opacity will become a named compliance problem within 18 months, as manufacturers submitting SBOMs for third-party conformity assessment discover that assessors require component-level disclosure that the blobs do not support.
The CRA's SBOM requirement under Article 10 is stated at the level of 'software components.' Third-party assessment bodies conducting Class II conformity assessments will interpret this requirement strictly when they encounter blobs with no sub-component disclosure. Manufacturers will escalate to SoC vendors for component manifests. Most SoC vendors do not produce them. The impasse will require either new SoC vendor obligations or explicit SBOM scope carve-outs in harmonized standards.
Confidence: highPublished guidance from ENISA or a notified body on SBOM scope for binary blobs by Q3 2026 would confirm the problem is already being formally addressed. Absence of any guidance by Q1 2027 confirms the gap is being ignored.
What manufacturers say before the assessment, and what the assessment finds underneath
'We already have ISO 27001 certification. That covers our security management system. The CRA requirements should mostly be met.'
Root cause:ISO 27001 covers the organization's information security management system. The CRA covers the product. These are different scopes. ISO 27001 does not require testing the firmware extraction resistance of a physical device, validating OTA update rollback protection, or demonstrating that a deployed device can detect and report active exploitation. A manufacturer can hold a current ISO 27001 certificate and ship a product with a live JTAG interface, an incomplete SBOM, and no deployed telemetry. The certification says nothing about any of those things.
'Our SBOM is generated automatically from our build system. It's complete by definition -- it reflects everything that goes into the build.'
Root cause:Build system SBOM generation reflects what the build system knows about. It does not reflect what is inside precompiled binaries that enter the build as opaque artifacts. SoC vendor SDKs, Wi-Fi stack firmwares, and proprietary hardware abstraction layers arrive as binaries with no package manifest. The SBOM generator cannot enumerate their contents. The SBOM is complete relative to the build system's visibility. It is incomplete relative to the software actually running on the device.
'We notify users about updates through the app. The update obligation is met because users can always update.'
Root cause:The CRA's update obligation is not about making updates available. It is about ensuring that security updates are actually delivered, and that the device remains secure throughout its support period. A device that requires user action to receive a security update will have a significant share of its deployed population running unpatched firmware at any given time. The obligation requires the manufacturer to address this -- either through automatic updates, forced update prompts, or documented evidence that the user population achieves adequate patch rates. 'The update is available in the app' is not sufficient.
The attack surfaces the CRA covers that manufacturers are not testing
Physical attack surface
Most manufacturer security testing is network-focused: does the device expose unnecessary ports, does it encrypt its traffic, does the API authenticate properly. Physical attack surface testing -- debug interface extraction, flash chip direct read, side-channel analysis on cryptographic operations -- is almost universally absent from pre-CRA test programs. The CRA's 'unauthorized access' requirement covers physical access. A device that is physically accessible in its deployment environment -- which is most IoT devices -- has a physical attack surface that needs assessment.
Bootloader and secure boot validation
Secure boot is frequently listed in security documentation as implemented. What the documentation does not always reflect is the chain of trust. A secure boot implementation that validates the application firmware but not the bootloader itself has a gap: a bootloader with a known vulnerability can be exploited before the secure boot measurement begins. Validating secure boot means tracing the chain from ROM to application, not just confirming that signature verification happens at some point in the process.
Cryptographic key management in production
Devices are designed with key management in mind -- keys are generated, certificates are provisioned, encryption is implemented. What breaks in production is the provisioning process itself. Mass-production firmware images with shared private keys. Provisioning scripts that write keys to flash without verifying the write. Factory test modes left enabled on production units that bypass key validation. The design is sound. The manufacturing process introduces the vulnerability.
The conformity assessment process will not catch what matters most
This is a stated opinion, not a finding. The CRA's conformity assessment framework -- particularly the Class I self-declaration path -- will produce a wave of compliant-on-paper products that have not been tested against realistic attack scenarios. The harmonized standards that would define what 'adequate testing' means are not yet published. Manufacturers filling the vacuum with their own test scope will test what they know how to test: functional security, network exposure, credential defaults. They will not test firmware extraction via debug interfaces, rollback attacks on OTA mechanisms, or supply chain opacity in vendor blobs. These are the failures that produce exploited devices. The compliance documentation will be complete. The devices will be exploitable.
Counterargument
The strongest counterargument is that market surveillance authorities will develop enforcement practice over time, and that the CRA's ongoing reporting obligations -- particularly the 24-hour incident notification -- create continuous pressure on manufacturers to maintain real security, not just initial certification. That argument is correct over a five-year horizon. It does not address the products that will enter the market in 2025 and 2026 under self-declaration while the enforcement practice is still forming.
One thing to do before your next product review meeting
Pull the production firmware image from your most recently shipped connected device -- not from your build system, from a physical production unit. Attempt to extract it via JTAG or SWD. If you do not know whether those interfaces are electrically active on your production board, find out before a regulator or a researcher does. That single check tells you more about your CRA exposure than reviewing your Article 10 policy documentation for the third time. If you cannot do it in-house, it is the right first question to put to an external assessment. Everything else in the compliance program is downstream of knowing what is actually running on the device and how hard it is to read.
Further Reading
Gap Analysis
compliance gap analysisVulnerability Assessment
vulnerability assessment servicesEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
EU Cyber Resilience Act compliance for connected devices in 2026NIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionNIST Cybersecurity Framework 2.0
NIST Cybersecurity Framework 2.0CISA Known Exploited Vulnerabilities
CISA known exploited vulnerabilities
Frequently Asked Questions
Does ISO 27001 certification satisfy EU Cyber Resilience Act requirements?
No. ISO 27001 covers an organization's information security management system. The CRA covers the product itself. ISO 27001 does not require testing firmware extraction resistance, OTA update rollback protection, or deployed device telemetry for incident detection. A manufacturer can hold a current ISO 27001 certificate and still ship a product with a live JTAG debug interface and an incomplete SBOM -- both CRA violations.
What does 'reasonably foreseeable misuse' mean for CRA Article 10 testing?
It means testing attack scenarios beyond the product's intended function. For a connected device, this includes firmware extraction via debug interfaces, credential extraction from device memory, OTA downgrade attacks using validly signed old firmware, and using the device as a network pivot. Most manufacturers' QA programs test intended use. The CRA requires testing foreseeable misuse, and the two scopes overlap only partially.
Why is my build system SBOM incomplete for CRA compliance?
Build system SBOM tools enumerate components from package manifests and build artifacts. They cannot enumerate the software inside precompiled binary blobs from SoC vendors -- Wi-Fi stacks, modem firmware, proprietary SDKs. These blobs arrive as single opaque artifacts. The software components inside them, including any with known CVEs, are invisible to automated SBOM generation.
What is the 24-hour reporting requirement under CRA Article 11?
Manufacturers must notify the relevant national authority within 24 hours of becoming aware that a vulnerability in their product is being actively exploited. The clock starts at awareness, not at public disclosure. Without deployed device telemetry that can detect active exploitation, manufacturers typically learn about exploitation from public sources -- by which point the 24-hour window has already closed.
How do I check whether my production device has an active JTAG or SWD interface?
The absence of a populated debug header does not mean the interface is disabled. Obtain a production unit and probe the board for JTAG or SWD test pads or unpopulated footprints near the SoC. Attempt to connect a debug adapter. If the interface responds, it is electrically active regardless of what the schematic or documentation states. This requires hands-on hardware assessment -- it cannot be determined from documentation review.
What is a CRA rollback attack on an OTA update mechanism?
A rollback attack uses a validly signed older firmware package to downgrade a device to a vulnerable version the manufacturer has already patched. If the OTA mechanism validates the signature but does not enforce a minimum firmware version, any signed package -- including old ones the manufacturer distributed -- can be installed. The signature check passes. The device runs vulnerable firmware. Rollback protection requires enforcing a monotonic version counter or minimum version policy in the bootloader.
When does EU Cyber Resilience Act enforcement begin?
The CRA's vulnerability and incident reporting obligations applied from September 2026. The full product requirements, including conformity assessment and CE marking, apply from December 2027. Manufacturers placing products on the EU market after those dates without meeting the applicable requirements face market withdrawal and financial penalties from national market surveillance authorities.
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.