Last Updated on September 1, 2026 by Narendra Sahoo
A CRA compliance gap assessment compares what your organization does with what Regulation (EU) 2024/2847 requires. It reviews each product and each role. It then produces a prioritized list of shortfalls. The list includes named owners, evidence pointers, and dates. It is not a conformity assessment. A conformity assessment decides whether a product may carry the CE marking. A gap assessment tells you whether you would survive one.
Source: European Commission, CRA summary of the legislative text.
What is a CRA compliance gap assessment?
The CRA places most of its weight on manufacturers, and it does so in three layers that a gap assessment has to test separately.
Gap assessment vs conformity assessment vs internal audit
A gap assessment is diagnostic. It has no legal status. That is precisely why it can be honest in a way that a conformity assessment cannot afford to be.
VISTA InfoSec’s CRA compliance consultants run a scoping and classification exercise across your full portfolio. This includes legacy and white-labeled products. They deliver a requirement-level gap register, not a generic checklist.
The four scoping decisions to make before you test anything
Four decisions, each made per product rather than per company.
How to test Annex I Part I: the thirteen product-property requirements
These thirteen apply on the basis of the manufacturer’s cybersecurity risk assessment, and where applicable. For each product, apply the gap question in the middle column and require the evidence in the right.
| Requirement | The gap question | Evidence that closes it |
|---|---|---|
| (a) No known exploitable vulnerabilities at release | Does a gate block release with one open? | Dated release-gate record per build |
| (b) Secure default configuration, resettable | Does the default need no hardening? Can it reset? | Default baseline, reset function, test result |
| (c) Vulnerabilities addressable by update, automatic where applicable | Can every supported version be updated? | Update and opt-out design, coverage matrix |
| (d) Protection from unauthorised access, and reporting of it | Is access control implemented and access surfaced? | Design record and test results |
| (e) Confidentiality of stored and transmitted data | Is relevant data encrypted at rest and in transit? | Cryptographic inventory with key management |
| (f) Integrity of data, commands, programs, configuration | Is unauthorised modification blocked and detected? | Secure boot, signing, integrity-check evidence |
| (g) Data minimisation | Can every data element be justified against purpose? | Data inventory mapped to purpose |
| (h) Availability of essential functions after an incident | Do core functions survive and recover from DoS? | Resilience test results, degraded-mode design |
| (i) No degradation of other devices and networks | Could this product harm other services? | Network behaviour analysis, rate limiting |
| (j) Limited attack surface | Is the interface inventory complete, unused ones off? | Interface inventory, justified per interface |
| (k) Exploitation mitigation | Are mitigations enabled in the shipping build? | Build configuration evidence |
| (l) Security logging with user opt-out | Are security events recorded, with an opt-out? | Event catalogue, retention design, opt-out |
| (m) Secure permanent deletion | Can a user erase all data and settings? | Factory-reset behaviour and verification test |
The “where applicable” trap
Article 13(3) & 13(4): Three states, not two
Article 13(3) requires the risk assessment to state whether and how each Part I requirement applies. Article 13(4) goes further: where one does not apply, the technical documentation must carry a clear justification.
Marking a requirement “not applicable” without a reason is not a clean result. It is an unmet documentation obligation, and an authority can find it by reading the technical file without touching the product.
Record three states, not two: applicable and met · applicable and not met · not applicable with a documented justification. A fourth state — not applicable, no justification — is always a finding.
How to test Annex I Part II: the eight vulnerability-handling requirements
These eight apply from the moment the product is on the market, for the whole support period. Unlike Part I, they are not conditioned on the risk assessment — they apply without qualification.
| Requirement | The gap question | Evidence that closes it |
|---|---|---|
| 1. SBOM in a common machine-readable format, at least top-level dependencies | Per release, or generated once? | CycloneDX or SPDX artefacts tied to versions |
| 2. Remediate without delay; security updates separate from features | Can a fix ship without a feature release? | Remediation SLA, security-only release history |
| 3. Regular security testing and review | Regular, or point-in-time? | Dated test scopes and results across releases |
| 4. Disclose fixed vulnerabilities once an update exists | Do advisories name product, impact, severity, remedy? | Published advisory archive |
| 5. Coordinated vulnerability disclosure policy | Published, and actually followed? | Policy plus case records showing it operating |
| 6. Facilitate reporting, including a contact address | Is the address monitored and triaged? | Intake and triage logs |
| 7. Secure update distribution | Signed, trusted channel, rollback protection? | Signing and distribution design, verification |
| 8. Updates disseminated without delay, free, with advisories | Free, with guidance on what to do? | Release notes and advisory templates |
The Article 13 duties outside Annex I
These are the duties that gap assessments organised purely around Annex I miss entirely. They are also among the easiest for an authority to check.
| Duty | Provision | Common gap |
|---|---|---|
| Determine the support period and record the reasoning | 13(8) | Five years asserted with no analysis of expected time in use |
| State the support end date, month and year, at the time of purchase | 13(19) | Buried in a support policy rather than shown at point of sale |
| Single point of contact not limited to automated tools | 13(17) | Chatbot or web form only, with no human channel |
| Due diligence on third-party and open-source components | 13(5) | Institutional knowledge, not a record |
| Report component vulnerabilities upstream and share the fix | 13(6) | No upstream reporting path at all |
| Keep technical documentation, the declaration of conformity and issued security updates available for ten years, or the support period if longer | 13(9), 13(13) | Held in systems with far shorter retention |
VISTA InfoSec audits your technical documentation against the ten-year retention standard and the full Article 13 duty list, and hands you a prioritised remediation plan with named owners and dates.
How to score and prioritise what you find
Generic high, medium and low severity is not useful here. Score by the clock a gap sits under — which statutory deadline it hits determines how urgently it needs to be closed.
Close P1 items first regardless of cost. Start P2 next despite the later date, because it depends on notified body capacity you do not control.
Before recording anything as met, apply three tests. Does the evidence exist as an artefact rather than a practice? Is it current and tied to a version? Would it answer a reasoned request under Article 13(22) without someone there to explain it?
What most organisations miss about CRA gap assessments
The presumption of conformity is not available yet
Article 27 grants it only for harmonised standards cited in the Official Journal. Standardisation request M/606 covers around 41 standards, still in development at CEN, CENELEC and ETSI. Industry trackers reported through mid-August 2026 that none had been cited. Confirm the current position — but if it holds, Article 32(2)’s lighter self-assessment route for Important Class I is narrower than it looks. Build direct evidence against Annex I rather than a plan that assumes standards arrive on schedule.
Five years is a floor, not a default
Article 13(8) requires the support period to reflect expected time in use, with five years as a minimum. The Commission’s July 2026 guidance says explicitly that five years should not be treated as the default for all products. For industrial controls and network equipment that stay in the field for a decade, a declared five-year period is a finding — and one no amount of documentation closes, because it is a product and commercial decision.
The vulnerability duty runs upstream, not just downstream
Article 13(6) requires a manufacturer that finds a vulnerability in an integrated component — open source included — to report it to whoever maintains that component and share the fix where one was developed. Few organisations have a path for this. Test it directly: ask who filed the last upstream vulnerability report, and when.
Notified body availability is a schedule risk, not a compliance gap
Chapter IV has applied since 11 June 2026. Bodies appear on the Commission’s NANDO system once notified. If you have Important Class II or Critical products, the gap is queue time in a market still forming. Start the notified body engagement early regardless of the 2027 date.
A realistic sequence for running the assessment
Compliance work overlaps rather than proceeding in a line, so think in phases rather than weeks.
Common mistakes
- Testing the company rather than the product. CRA findings attach to products. An organisation-level maturity score is not a gap assessment.
- Starting with the requirements rather than the scope. If the product register is wrong, every finding is mis-attributed.
- Treating the two deadlines as one. This produces either a September failure or a large amount of premature work.
- Accepting a design document as evidence of a shipped behaviour. Assess the build, not the specification.
- Assuming harmonised standards will arrive in time to be the plan. Build direct evidence and treat cited standards as an improvement when they land.
- Reviewing only the OEM side of white-label arrangements. Article 21 moves obligations to whoever puts their name on the box.
- Recording “not applicable” without a justification. A documentation finding hiding as a clean result.
Frequently Asked Questions
Still treating the CRA as a 2027 problem?
Article 14 reporting has applied since September 2026. VISTA InfoSec’s CRA gap assessment covers scoping, classification, all 21 Annex I requirements, Article 14 reporting readiness and technical documentation — so you know exactly where you stand while fixing gaps is still cheap.
Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.
