❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

CRA Compliance Gap Assessment: How to Identify Your Compliance Gaps

✇VISTA InfoSec
By: Narendra Sahoo
1 September 2026 at 02:49
5/5 - (1 vote)

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.

10 Dec 2024CRA entered into force
11 Sept 2026 ⚠Article 14 reporting live — 24-hour clock starts. No grandfather clause for products already on market.
11 Dec 2027Full application — essential requirements, conformity assessment, CE marking

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.

Layer 1
Product properties
The thirteen requirements in Annex I, Part I, point 2: secure defaults, access control, confidentiality, integrity, data minimisation, availability, attack-surface limitation, logging and secure deletion.
Layer 2
Vulnerability handling
The eight process requirements in Annex I, Part II, apply for the whole support period.These include SBOM, remediation, security testing, disclosure, a CVD policy, and secure update distribution.
Layer 3
Operator obligations
Duties in Article 13 and Articles 19–23 are not essential requirements. These duties include the support period, documentation, and retention. They also include the single point of contact, CE marking, and Article 14 reporting.
Most gap assessments fail because they test the first layer well, the second layer partly, and the third layer not at all.

Gap assessment vs conformity assessment vs internal audit

Activity Question it answers Who performs it When
Gap assessment Where do we fall short, and how bad is each shortfall? Internal team or external adviser Any time; ideally well before a deadline
Conformity assessment May this product carry the CE marking? Manufacturer (Module A self-assessment) or a notified body (modules B+C or H) Before placing the product on the market
Internal audit Are our own defined processes being followed? Internal audit function On a recurring cycle

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.

Get expert help
Not sure where to begin your CRA gap assessment?

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.

1
Is the product actually in scope?
The CRA covers products with digital elements sold in the EU market. Their intended or expected use includes a direct or indirect data connection.A cloud back end is part of the product if the maker built it.The product also must not work without it.Standalone SaaS usually is not part of the product.It typically falls under NIS2. Medical devices, type-approved vehicles, certified aviation products and defence products are excluded.
2
Which economic operator are you, for this product?
Article 21 catches people. An importer or distributor who sells a product under its own name or trademark becomes the manufacturer.If it makes major changes to a product, it also becomes the manufacturer.It then assumes all manufacturer duties, including Article 14 reporting. Review only the OEM side of a white-label deal and the rebrander’s exposure stays invisible.
3
Which classification tier applies?
Classification follows core functionality, not the product name, assessed against Annexes III and IV and the technical descriptions in Implementing Regulation (EU) 2025/2392. Default products self-assess. Important Class I may self-asstant Class II and Critical products need a notified body.
4
Which deadline does this gap hit?
Article 14 reporting applies from 11 September 2026 to every in-scope product already on the market, with no grandfather clause. Everything else applies from 11 December 2027, catching earlier products only if they are substantially modified after that date. Confuse the two clocks and you either miss September or over-build for December.

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
Key principle: A design intention in a specification is not evidence. Assess the shipping build.

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 usual structural finding: Requirements 1, 4 and 5 exist as documents while 2, 3 and 6 exist as habits. Habits produce no evidence.

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
Retention is structural, not technical. A product placed on the market in December 2027 with a ten-year support period generates records that must stay retrievable into the late 2030s. Most engineering artefact stores are not built for that.

Close your documentation gaps
Article 13 gaps are often the easiest to close — once you know where they are.

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.

Class Definition Deadline
P1 Reporting Cannot detect, assess or notify inside the Article 14 windows 11 Sept 2026
P2 Market-access Blocks the conformity route the tier requires 11 Dec 2027
P3 Requirement An applicable Annex I requirement is not met 11 Dec 2027
P4 Documentation Control operates, evidence does not exist 11 Dec 2027
P5 Structural Materialises later but must be designed for now Ongoing

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.

1
Phase 1
Scope and classify
Build or validate the product register, assign the economic-operator role per product, and classify each product against Annex III and IV using the technical descriptions in Implementing Regulation (EU) 2025/2392. Output: a scope register you would be willing to hand to an authority.
2
Phase 2
Test at requirement level
Work the Annex I Part I matrix, the Part II matrix and the Article 13 duties per product. Record three states, not two, and demand an artefact for every “met”. This is the longest phase and the one most often compressed. Expect it to surface more documentation gaps than control gaps.
3
Phase 3
Rehearse the reporting pathway
Determine the main establishment for Article 14 purposes, identify the coordinating CSIRT, confirm who is authorised to file, and run the 24-hour and 72-hour sequence as a live exercise. ENISA’s Single Reporting Platform is intended to be operational from September 2026. A rehearsal produces findings that a policy document cannot.
4
Phase 4
Score, assign and schedule
Classify every finding P1 to P5, assign a named owner and a date, and map each item to its statutory deadline. Anything without an owner is not a plan. Where an external assessor genuinely adds value is in Phase 1 and Phase 3: classification calls carry real consequences, and a reporting rehearsal is more useful when someone outside the team is running the clock.

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

Do We need a gap assessment if everything is Default tier
Yes. Tier affects the conformity route only. Annex I, the Article 13 duties and Article 14 reporting apply regardless of whether your products are Default, Important or Critical.
Does the CRA apply to products we sold years ago?
For Article 14 reporting, yes — there is no grandfather clause. Products already on the EU market when the reporting obligations went live on 11 September 2026 are in scope. For the broader obligations applying from 11 December 2027, earlier products are only caught if substantially modified after that date.
Can we rely on harmonised standards yet?

Verify before assuming. Trackers reported through mid-August 2026 that none had been cited in the Official Journal.

What are the CRA penalties?
Article 64 sets three tiers, applied nationally. Breaching Annex I or Articles 13 and 14 reaches €15 million or 2.5% of worldwide annual turnover, whichever is higher; other obligations €10 million or 2%; misleading information to authorities €5 million or 1%. Authorities can also order corrective action, restriction, withdrawal or recall.
How lond does a CRA gap assessment take?
It depends on portfolio size and how accurate the product register is at the outset. The requirement-level testing phase (Phase 2) is typically the longest. Organisations with mature ISO 27001 or IEC 62443 documentation generally move through it faster, as the record-keeping discipline transfers directly even though the two frameworks serve different purposes.

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.

The post CRA Compliance Gap Assessment: How to Identify Your Compliance Gaps appeared first on Information Security Consulting Company - VISTA InfoSec.

CRA Compliance Gap Assessment: How to Identify Your Compliance Gaps

✇VISTA InfoSec
By: Narendra Sahoo
1 September 2026 at 02:49
5/5 - (1 vote)

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.

10 Dec 2024CRA entered into force
11 Sept 2026 ⚠Article 14 reporting live — 24-hour clock starts. No grandfather clause for products already on market.
11 Dec 2027Full application — essential requirements, conformity assessment, CE marking

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.

Layer 1
Product properties
The thirteen requirements in Annex I, Part I, point 2: secure defaults, access control, confidentiality, integrity, data minimisation, availability, attack-surface limitation, logging and secure deletion.
Layer 2
Vulnerability handling
The eight process requirements in Annex I, Part II, apply for the whole support period.These include SBOM, remediation, security testing, disclosure, a CVD policy, and secure update distribution.
Layer 3
Operator obligations
Duties in Article 13 and Articles 19–23 are not essential requirements. These duties include the support period, documentation, and retention. They also include the single point of contact, CE marking, and Article 14 reporting.
Most gap assessments fail because they test the first layer well, the second layer partly, and the third layer not at all.

Gap assessment vs conformity assessment vs internal audit

Activity Question it answers Who performs it When
Gap assessment Where do we fall short, and how bad is each shortfall? Internal team or external adviser Any time; ideally well before a deadline
Conformity assessment May this product carry the CE marking? Manufacturer (Module A self-assessment) or a notified body (modules B+C or H) Before placing the product on the market
Internal audit Are our own defined processes being followed? Internal audit function On a recurring cycle

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.

Get expert help
Not sure where to begin your CRA gap assessment?

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.

1
Is the product actually in scope?
The CRA covers products with digital elements sold in the EU market. Their intended or expected use includes a direct or indirect data connection.A cloud back end is part of the product if the maker built it.The product also must not work without it.Standalone SaaS usually is not part of the product.It typically falls under NIS2. Medical devices, type-approved vehicles, certified aviation products and defence products are excluded.
2
Which economic operator are you, for this product?
Article 21 catches people. An importer or distributor who sells a product under its own name or trademark becomes the manufacturer.If it makes major changes to a product, it also becomes the manufacturer.It then assumes all manufacturer duties, including Article 14 reporting. Review only the OEM side of a white-label deal and the rebrander’s exposure stays invisible.
3
Which classification tier applies?
Classification follows core functionality, not the product name, assessed against Annexes III and IV and the technical descriptions in Implementing Regulation (EU) 2025/2392. Default products self-assess. Important Class I may self-asstant Class II and Critical products need a notified body.
4
Which deadline does this gap hit?
Article 14 reporting applies from 11 September 2026 to every in-scope product already on the market, with no grandfather clause. Everything else applies from 11 December 2027, catching earlier products only if they are substantially modified after that date. Confuse the two clocks and you either miss September or over-build for December.

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
Key principle: A design intention in a specification is not evidence. Assess the shipping build.

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 usual structural finding: Requirements 1, 4 and 5 exist as documents while 2, 3 and 6 exist as habits. Habits produce no evidence.

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
Retention is structural, not technical. A product placed on the market in December 2027 with a ten-year support period generates records that must stay retrievable into the late 2030s. Most engineering artefact stores are not built for that.

Close your documentation gaps
Article 13 gaps are often the easiest to close — once you know where they are.

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.

Class Definition Deadline
P1 Reporting Cannot detect, assess or notify inside the Article 14 windows 11 Sept 2026
P2 Market-access Blocks the conformity route the tier requires 11 Dec 2027
P3 Requirement An applicable Annex I requirement is not met 11 Dec 2027
P4 Documentation Control operates, evidence does not exist 11 Dec 2027
P5 Structural Materialises later but must be designed for now Ongoing

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.

1
Phase 1
Scope and classify
Build or validate the product register, assign the economic-operator role per product, and classify each product against Annex III and IV using the technical descriptions in Implementing Regulation (EU) 2025/2392. Output: a scope register you would be willing to hand to an authority.
2
Phase 2
Test at requirement level
Work the Annex I Part I matrix, the Part II matrix and the Article 13 duties per product. Record three states, not two, and demand an artefact for every “met”. This is the longest phase and the one most often compressed. Expect it to surface more documentation gaps than control gaps.
3
Phase 3
Rehearse the reporting pathway
Determine the main establishment for Article 14 purposes, identify the coordinating CSIRT, confirm who is authorised to file, and run the 24-hour and 72-hour sequence as a live exercise. ENISA’s Single Reporting Platform is intended to be operational from September 2026. A rehearsal produces findings that a policy document cannot.
4
Phase 4
Score, assign and schedule
Classify every finding P1 to P5, assign a named owner and a date, and map each item to its statutory deadline. Anything without an owner is not a plan. Where an external assessor genuinely adds value is in Phase 1 and Phase 3: classification calls carry real consequences, and a reporting rehearsal is more useful when someone outside the team is running the clock.

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

Do We need a gap assessment if everything is Default tier
Yes. Tier affects the conformity route only. Annex I, the Article 13 duties and Article 14 reporting apply regardless of whether your products are Default, Important or Critical.
Does the CRA apply to products we sold years ago?
For Article 14 reporting, yes — there is no grandfather clause. Products already on the EU market when the reporting obligations went live on 11 September 2026 are in scope. For the broader obligations applying from 11 December 2027, earlier products are only caught if substantially modified after that date.
Can we rely on harmonised standards yet?

Verify before assuming. Trackers reported through mid-August 2026 that none had been cited in the Official Journal.

What are the CRA penalties?
Article 64 sets three tiers, applied nationally. Breaching Annex I or Articles 13 and 14 reaches €15 million or 2.5% of worldwide annual turnover, whichever is higher; other obligations €10 million or 2%; misleading information to authorities €5 million or 1%. Authorities can also order corrective action, restriction, withdrawal or recall.
How lond does a CRA gap assessment take?
It depends on portfolio size and how accurate the product register is at the outset. The requirement-level testing phase (Phase 2) is typically the longest. Organisations with mature ISO 27001 or IEC 62443 documentation generally move through it faster, as the record-keeping discipline transfers directly even though the two frameworks serve different purposes.

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.

The post CRA Compliance Gap Assessment: How to Identify Your Compliance Gaps appeared first on Information Security Consulting Company - VISTA InfoSec.

Cyber Resilience Act Compliance Checklist: 15 Steps to Prepare Before 2027

✇VISTA InfoSec
By: Narendra Sahoo
17 August 2026 at 07:10
5/5 - (1 vote)

Last Updated on August 17, 2026 by Narendra Sahoo

The EU Cyber Resilience Act makes cybersecurity a condition of market access. A product with digital elements sold in the EU must demonstrate security by design, secure defaults and working vulnerability management — or it does not get a CE mark. This Cyber Resilience Act compliance checklist
turns Regulation (EU) 2024/2847 into 15 steps, in execution order.

It entered into force on 10 December 2024 and applies in full from 11 December 2027. But the first enforceable obligation — reporting actively exploited vulnerabilities and severe incidents — began on 11 September 2026, and under Article 69(3) it covers products already on the market. Anyone treating 2027 as the start line has already missed a deadline.

The Three Dates That Drive Your Programme

11 Jun 2026
Chapter IV applies — notified bodies can be designated, third-party assessment becomes possible
11 Sept 2026
Article 14 reporting applies — 24-hour / 72-hour / 14-day clock via the ENISA single reporting platform
11 Dec 2027
Full application — essential requirements, conformity assessment, technical documentation, CE marking

Figure 1: Cyber Resilience Act compliance timeline — key application dates under Regulation (EU) 2024/2847

Who the Cyber Resilience Act Applies To

The CRA covers products with digital elements — software or hardware, plus the remote data-processing solutions they need to function — whose intended or foreseeable use includes a direct or indirect data connection to a device or network. Manufacturers carry almost the entire obligation set. Importers must verify conformity assessment, CE marking and documentation; distributors must check CE marking and user information and halt distribution where non-compliance is suspected.

Article 2 excludes products covered by the Medical Devices and IVD Regulations, motor vehicles, certified civil aviation products, marine equipment, spare parts, and products developed exclusively for national security, defence or classified information. No carve-out is as broad as vendors assume — which is why Step 1 is a documented decision, not an assumption.

The 15-Step Cyber Resilience Act Compliance Checklist

Each step below names the article that drives it and the deliverable an auditor will actually ask to see. Work through them in order — later steps assume the scoping, classification and risk-assessment decisions made earlier are already on paper.

Phase 1 — Scope and Classification

1Confirm whether the CRA applies

Test each product, not the company. A product is in scope if it has digital elements, connects directly or indirectly to a device or network, and is sold commercially in the EU. Separate standalone SaaS from remote data-processing solutions integral to a product’s function — the latter are in scope as part of the product.

📋 Deliverable: A scoping register: decision, legal basis and owner per product.
2Classify the product: default, important or critical

This decision drives cost and lead time, because it determines whether you can self-assess. Most products sit in the default tier. Annex III Part A (Class I) can self-assess only where harmonised standards, common specifications or an EU certification scheme cover all applicable requirements; Part B (Class II) cannot self-assess at all; Annex IV critical products may need an EU certificate by delegated act. Classification follows core functionality, not embedded components — use Implementing Regulation (EU) 2025/2392.

📋 Deliverable: A classification matrix: tier and conformity route per product.

Figure 2: CRA product classification tiers and the conformity assessment route each one triggers

3Fix your role and your legal exposure

Sell a product under your own name, or substantially modify one already on the market, and you become the manufacturer with the full obligation set. Define what substantial modification means for your products before a release forces the question, and push CRA duties into supplier contracts.

📋 Deliverable: A role matrix, the authorised representative mandate, revised contracts.

Not sure how the CRA classifies your products?

VISTA InfoSec’s CRA compliance consultants run the scoping and classification exercise across your full portfolio — including legacy and white-labelled SKUs — before a regulator asks first.

Explore CRA Compliance Services →

Phase 2 — Engineer Compliance Into the Product

4Run a documented cybersecurity risk assessment

Article 13(2) requires a risk assessment per product, kept current through the support period and included in the technical documentation. It determines which Annex I requirements apply and how, so every other decision leans on it. Cover intended and foreseeable use, including misuse.

📋 Deliverable: A versioned assessment with an applicability decision per Annex I requirement.
5Close the Annex I Part I gaps

Products must be made available without known exploitable vulnerabilities and, subject to the risk assessment, must deliver secure defaults with reset, access control, confidentiality and integrity protection, data minimisation, DoS resilience, limited attack surfaces, exploitation mitigation, logging with a user opt-out, and secure permanent data deletion. Harmonised standards under request M/606 have slipped, so build against the annex text.

📋 Deliverable: A gap register: requirement, control, test evidence, sign-off.
6Set, justify and publish the support period

Under Article 13(8) the period must reflect expected use and be at least five years unless the lifetime is demonstrably shorter. Article 13(19) requires the end date, month and year, at the point of purchase, and Article 13(9) requires each update to stay available for ten years after issue. Cost it before committing publicly.

📋 Deliverable: A documented determination and proof the end date is disclosed at purchase.
7Produce a machine-readable SBOM

Annex I Part II(1) requires a software bill of materials in a commonly used and machine-readable format covering at the very least top-level dependencies. Generate it in CI/CD as SPDX or CycloneDX per release, covering firmware and OS packages as well as libraries, and wire it into vulnerability monitoring.

📋 Deliverable: Per-release SBOM artefacts retained for the support period.
8Vet third-party and open-source components

Article 13(5) requires due diligence when integrating third-party components. Annex I Part II adds that on identifying a vulnerability in one you must remediate it and report it to whoever maintains that component. Using an open-source library does not move the risk to its maintainers, so plan a route to fix, fork or replace when upstream is unresponsive.

📋 Deliverable: A due diligence file per dependency and records of upstream reports.
Need help closing your Annex I gaps?

We map your current controls to every Annex I requirement, build your SBOM process, and hand you a prioritised gap register — not a generic checklist.

Talk to a CRA Compliance Consultant →

Phase 3 — Operate Vulnerability Handling and Reporting

9Build the vulnerability handling process

Annex I Part II sets eight process obligations across the support period: document components and vulnerabilities; remediate without delay; test and review regularly; disclose fixed vulnerabilities with impact, severity and remediation guidance; enforce a disclosure policy; provide a reporting contact; distribute updates securely; and ship security updates free of charge with advisories.

📋 Deliverable: A documented process with owners, severity tiers, targets and metrics.
10Publish a coordinated vulnerability disclosure policy

Two requirements are visible from outside your organisation, making them a natural first check for an authority: a coordinated disclosure policy, and a contact address for reporting vulnerabilities in your product or its components. Publish at a stable URL, add security.txt, and log every report — enforcing the policy is itself the obligation.

📋 Deliverable: The published policy, security.txt, a timestamped intake log.
11Stand up Article 14 reporting

Live since 11 September 2026 and, under Article 69(3), applicable to products already placed on the EU market. Notify through the ENISA single reporting platform to your coordinating CSIRT and to ENISA: early warning within 24 hours of becoming aware, notification within 72 hours, and a final report within 14 days of a corrective measure becoming available for a vulnerability, or one month for a severe incident. Article 3(42) defines an actively exploited vulnerability, but the CRA does not define the severity threshold, so your criteria must be written down. Article 14(8) also requires you to inform impacted users.

📋 Deliverable: A procedure with named decision-makers, platform registration, templates, a tabletop record.

Figure 3: The CRA Article 14 reporting clock — 24 hours, 72 hours and the final report

12Engineer secure, free and timely security updates

Sign updates, verify signatures on the device, protect the delivery channel and support rollback. Where technically feasible, security updates must be delivered separately from functionality updates, and they must be disseminated without delay and free of charge with advisory messages — no security fix behind a support contract. Design so a failed update cannot brick a fielded device.

📋 Deliverable: Update architecture docs, signing test results, channel separation evidence.
T0
Event Detected
24 HRS
Early Warning
72 HRS
Notification
14 DAYS / 1 MO.
Final Report

Not confident you could hit the 24-hour reporting clock today?

VISTA InfoSec builds and rehearses your Article 14 reporting pathway — platform registration, named decision-makers and a tabletop exercise — before a real vulnerability starts the clock.

Explore CRA Compliance Services →

Phase 4 — Attest, Mark and Sustain

13Choose the conformity assessment route

Default products use internal control (Module A). Class I can self-assess only with full standards coverage. Class II needs a notified body or an EU certification scheme at assurance level at least ‘substantial’. Modules B, C and H are also available. Chapter IV only applied from 11 June 2026, so notified body capacity is scarce — engage early.

📋 Deliverable: The route decision per product and a standard-to-requirement mapping.
14Compile the attestation package

Annex VII technical documentation covers the product description, design and development detail, the risk assessment, vulnerability handling, the support period, standards applied and test reports. Annex II sets the user information. Then draw up the Annex V declaration of conformity and affix the CE marking. Article 13(13) requires both to stay available to authorities for ten years after placing on the market, or the support period, whichever is longer.

📋 Deliverable: The technical file, signed declaration, CE approval, retention controls.
15Operationalise post-market surveillance

Authorities can require information, order corrective action and restrict, withdraw or recall a product — what protects you is producing current evidence quickly. Assign an owner per product line, set a review cadence that keeps the risk assessment, SBOM, technical file and declaration current, and make substantial modification a release gate.

📋 Deliverable: A governance charter, review records, a tested response procedure.

Cyber Resilience Act Penalties

Article 64 sets three tiers. The higher of the fixed amount and the turnover percentage applies.

Maximum Fine Applies To
€15M / 2.5% Breach of the Annex I essential requirements and the manufacturer obligations in Articles 13 and 14, including reporting.
€10M / 2% Other obligations: importer and distributor duties, the declaration of conformity, CE marking, conformity assessment.
€5M / 1% Incorrect, incomplete or misleading information given to notified bodies or authorities.

Figures are the higher of the fixed amount or the percentage of worldwide annual turnover.

TWO RELIEF PROVISIONS

Article 64(10)(a): micro and small enterprises are not fined for missing either 24-hour early warning deadline — all other deadlines still apply. Article 64(10)(b): open-source software stewards are not subject to administrative fines — this does not extend to commercial manufacturers.

Where Programmes Go Wrong

COMMON MISTAKES TO AVOID

✘  Treating December 2027 as the deadline. Article 14 reporting has applied since September 2026, to products already on the market.
✘  Waiting for harmonised standards. The obligation is compliance with Annex I, not with a standard that may arrive late.
✘  Classifying by component. A product is not Class I because it contains a crypto library — only if the Annex III functionality is what it is for.

Client Case Study

Profile

A mid-sized industrial IoT manufacturer (~200 employees) exporting connected sensor gateways and controllers to 12 EU member states through a
mix of direct sales and regional distributors.

The Assumption Went In With

CRA exposure was limited to its two current-generation product lines. Older lines were assumed retired and out of scope.

What the Gap Assessment Found

A structured inventory turned up nine additional SKUs still active in distributor channels, including a discontinued gateway still receiving
security patches under a legacy support contract. Two of the nine had never been classified and, once tested against Annex III, landed in
Important Class I — changing the conformity route and documentation depth required. Separately, the risk assessment existed but lived outside
the technical file, the SBOM covered only top-level dependencies, and no one had been assigned to monitor the inbox that would receive an Article
14 report.

Illustrative Outcome

In a scenario like this, the full inventory and classification pass typically closes within 2–3 weeks, an SBOM pipeline can be wired into
CI/CD within 4–6 weeks, and a documented, tabletop-tested Article 14 reporting pathway is usually achievable well ahead of a hard deadline
— once the gaps are actually identified. The expensive part is rarely the fix; it is not knowing the gaps exist until someone looks.

How VISTA InfoSec Can Help

The CRA rewards organisations that reuse what they have. VISTA InfoSec engagements typically cover applicability and classification across the portfolio, an Annex I gap assessment mapped to existing ISO/IEC 27001 or IEC 62443 controls, Article 14 reporting readiness, and technical documentation preparation.

Talk to VISTA InfoSec about a CRA readiness assessment to work through this Cyber Resilience Act compliance checklist against your own products before 11 December 2027.

Ready to turn this checklist into an evidenced programme?

VISTA InfoSec’s CRA readiness assessment works through all 15 steps against your real product portfolio and hands you a prioritised remediation roadmap.

Talk to a CRA Compliance Consultant →

Frequently Asked Questions

When does the Cyber Resilience Act come into effect?
It entered into force on 10 December 2024 and applies in full from 11 December 2027. Chapter IV applied from 11 June 2026 and Article 14 reporting from 11 September 2026.
Does the Cyber Resilience Act apply to SaaS?
Standalone SaaS is generally outside the CRA and sits under NIS2. A remote data-processing solution necessary for a product to perform its functions is in scope as part of that product.
Is an SBOM mandatory under the CRA?
Yes. Annex I Part II requires one in a commonly used and machine-readable format covering at the very least top-level dependencies. It need not be published, but must be current and available to authorities.
What are the CRA reporting deadlines?
An early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a corrective measure being available for a vulnerability, or one month for a severe incident.
Does the CRA apply to products already on the market?
The substantive requirements apply to products placed on the market before 11 December 2027 only if substantially modified after that date. Reporting is the exception: under Article 69(3) Article 14 applies to in-scope products already on the market.
Does the CRA apply to non-EU manufacturers?
Yes, to any product made available on the EU market regardless of where the manufacturer is established. Appoint an EU authorised representative — this does not transfer responsibility for compliance.

The Bottom Line

The organisations that come through the first CRA enforcement wave cleanly are the ones treating this gap assessment as infrastructure, not paperwork: inventorying what they actually ship, classifying it honestly, and rehearsing the reporting pathway before a real vulnerability forces the question. An inventory can be built in weeks; fixing gaps found during a real incident takes a lot longer, and it happens under a 24-hour clock instead of on your own schedule.

VISTA InfoSec • EU Cyber Resilience Act Compliance Specialists

Still Treating the CRA as a 2027 Problem?

Article 14 reporting has applied since September 2026. VISTA InfoSec’s CRA compliance service covers scoping, classification, Annex I gap
assessment, SBOMs, reporting readiness and technical documentation — so you know exactly where you stand while fixing gaps is still cheap.

 

Explore CRA Compliance Services →

 

The post Cyber Resilience Act Compliance Checklist: 15 Steps to Prepare Before 2027 appeared first on Information Security Consulting Company - VISTA InfoSec.

EU CRA Gap Assessment: Are You Ready for 2026?

✇VISTA InfoSec
By: Narendra Sahoo
22 July 2026 at 07:05
Rate this post

Last Updated on July 23, 2026 by Narendra Sahoo

Most compliance teams have filed the EU Cyber Resilience Act under “2027” — the date the regulation becomes fully applicable. That’s the wrong filing date. From 11 September 2026, manufacturers must already report actively exploited vulnerabilities and severe incidents affecting products with digital elements, more than a year before the rest of the regulation takes effect. This guide covers the four areas a CRA gap assessment needs to test before that clock starts — inventory, classification, documentation, and the reporting pathway itself — current as of July 2026.

11 Sept 2026
Article 14 reporting obligations go live — no grandfather clause
24 Hrs
Early-warning deadline once a qualifying event is discovered
€15M / 2.5%
Top fine tier — whichever of the two is higher
4 Tiers
Default, Important Class I & II, Critical — by function, not name

1⃣ The Deadline That Arrives Before the CRA Is Even Fully in Force

A gap assessment run today has to answer a narrower, more urgent question than full CRA readiness: can this organisation detect, assess, and report a qualifying event within 24 hours, starting in September 2026? That’s a different deliverable than a multi-year compliance roadmap, and most manufacturers haven’t built it yet. The reporting clock is unforgiving once triggered — an early warning within 24 hours, a fuller notification within 72 hours, and a final report no later than fourteen days after a fix is available for vulnerabilities, or within one month for severe incidents.

💡 CRITICAL INSIGHT

These obligations apply to every in-scope product already on the EU market, including legacy products placed there long before the CRA existed. There is no grandfather clause — a product shipped in 2019 is in scope for a report filed in 2026 if it’s still in the field.

2⃣ Build the Product Inventory First

Nothing else in a gap assessment works without an accurate product inventory. It should cover new and legacy products, software and hardware, embedded components, remote data processing solutions, supported versions, and unsupported versions still in use. Most manufacturers underestimate this step: a portfolio review frequently turns up products nobody remembers actively shipping, white-labelled variants sold under a partner’s brand, and components inherited through acquisitions that were never reassessed. A product list alone isn’t enough — manufacturers also need to identify the responsible legal entity behind each product, since which national CSIRT receives a given report depends on correctly identifying the manufacturer’s main establishment.

✅ INVENTORY CHECKLIST

□  List every in-scope product, including legacy and unsupported versions still in the field
□  Flag white-labelled variants and components inherited through acquisitions
□  Map each product to the legal entity that qualifies as its manufacturer

Not sure your product inventory is actually complete?

VISTA InfoSec’s CRA compliance consultants build or validate your full product inventory and confirm which entity is the legal manufacturer for each item — before a regulator asks first.

Explore CRA Compliance Services →

3⃣ Classify Every Product Against Annex III

Once the inventory exists, every product needs a classification call: Default, Important Class I, Important Class II, or Critical, based on its core functionality rather than its name or marketing description. Skipping classification at the gap-assessment stage is the most common shortcut, and the most expensive one — the tier determines which conformity assessment module applies, which standards are relevant, and how deep the technical documentation needs to go.

Tier What It Covers Representative Examples Conformity Route
Default Everything not named in Annex III or IV Most general-purpose software and connected devices without elevated security functions Manufacturer self-assessment
Important – Class I Security-adjacent functions, moderate risk Password managers, VPN clients, identity/access management software, smart locks, cameras, baby monitors, connected toys Self-assessment against harmonised standards, or third-party review
Important – Class II Higher-risk security infrastructure Firewalls, intrusion detection/prevention systems, hypervisors, tamper-resistant microprocessors Mandatory third-party (notified body) assessment
Critical Foundational trust infrastructure Hardware security modules, smart cards and readers, tamper-resistant secure elements, smart meter gateways Mandatory third-party assessment; may require EU cybersecurity certification

Annex III and IV category definitions have been refined through 2025–26 implementing guidance — confirm current status against the latest published list before finalising a classification.

4⃣ Importer and Distributor Obligations Under Articles 20 and 21

Article 20 sets out importers’ general obligations: confirming that the manufacturer has met the product-related essential requirements, that vulnerability-handling processes exist, that the conformity assessment was properly carried out, and that technical documentation has been drawn up before a product carries the CE marking. Article 21 covers a narrower and easily missed case — when an importer or distributor places a product under its own name or trademark, or substantially modifies a product already on the market. At that point, the importer or distributor takes on the full set of manufacturer obligations, including the Article 14 reporting duties.

👉 IN PRACTICE — A WHITE-LABEL DISTRIBUTION DEAL

A distributor rebrands a connected sensor under its own trademark for a regional market. On paper, the original OEM is still “the manufacturer.” Under Article 21, it’s the distributor’s name on the box that now carries the Article 14 reporting duty — a gap assessment that only reviews the OEM’s side of this chain leaves that distributor’s exposure completely unmapped.

5⃣ Technical Documentation — Where the Backlog Usually Is

Technical documentation is where most gap assessments find their largest volume of unfinished work. The manufacturer must perform a cybersecurity risk assessment that informs how the essential requirements are implemented, and that risk assessment — along with the standards or measures chosen to meet those requirements — has to be part of the technical documentation itself, not held separately in someone’s inbox. Retention isn’t a minor footnote either: records must be kept for ten years or the product’s support period, whichever is longer. Organisations with an existing ISO 27001-aligned documentation practice usually find this easier — the record-keeping discipline transfers directly, even though the two frameworks serve different purposes.

Third-party components add a second layer: a manufacturer must exercise due diligence to confirm those components don’t compromise the finished product’s cybersecurity. This is where inventories fall short most often — software bills of materials are frequently incomplete or exist only for top-level dependencies, and due-diligence evidence for embedded components is often unwritten institutional knowledge rather than a documented control tied to a standard format like CycloneDX or SPDX.

✅ DOCUMENTATION CHECKLIST

□  Confirm the risk assessment lives inside the technical file, not a separate inbox
□  Test whether documentation formats can survive the ten-year retention window
□  Build or complete an SBOM in a standard format (CycloneDX/SPDX) for every product

Want your documentation retention-tested before an auditor does it for you?

Book a free 40-minute consultation with VISTA InfoSec to walk through your current technical documentation against the CRA’s ten-year retention standard.

Book Your Free 40-Minute Consultation →

6⃣ Pressure-Test the Reporting Pathway Itself

Knowing the rules isn’t the same as being able to execute them under a 24-hour clock. A gap assessment should map the relevant Single Reporting Platform route: determine the manufacturer’s main establishment for Article 14(7) purposes, identify the fallback route for non-EU manufacturers, and confirm which national CSIRT acts as coordinator. ENISA has indicated the platform will be operational by 11 September 2026, with a testing period beforehand — which makes a dry run, not just a policy document, the real test of readiness.

T0
Event Detected
24 HRS
Early Warning
72 HRS
Notification
14 DAYS / 1 MO.
Final Report

⚠ DON’T CONFUSE THESE TWO CLOCKS

Article 14‘s reporting duties start on 11 September 2026; Article 13‘s broader process requirements for products placed on the market don’t take full effect until December 2027. A gap assessment that confuses the two risks either under-preparing for the reporting deadline or over-building processes the organisation doesn’t need yet — both are avoidable with a clear read of which article applies when.

7⃣ Supply Chain and Contract Language

Supplier relationships are the part of a gap assessment most likely to get skipped, and they carry real exposure. Supplier contracts should be updated to reflect CRA obligations, with CRA compliance built into supplier due-diligence procedures. Suppliers of critical components that could affect a manufacturer’s ability to comply by December 2027 should be prioritised for review now. If your supply chain also touches essential or important entities under NIS2, the two due-diligence exercises overlap enough to run as one review rather than two.

Haven’t reviewed your supplier contracts for CRA exposure yet?

VISTA InfoSec reviews supplier and OEM contracts for CRA-relevant due-diligence and notification clauses, prioritising critical-component suppliers first.

Explore CRA Compliance Services →

8⃣ The Six-Point CRA Readiness Checklist

✅ FULL READINESS CHECKLIST

□  Inventory every in-scope product — new, legacy, supported, unsupported — and confirm the legal manufacturer for each
□  Classify each product as Default, Important Class I, Important Class II, or Critical
□  Map the Article 20/21 chain of manufacturer, importer, and distributor obligations
□  Audit technical documentation against the ten-year retention requirement
□  Dry-run the Single Reporting Platform pathway, including the 24-hour and 72-hour clocks
□  Review supplier contracts for CRA-relevant due-diligence and notification clauses

9⃣ What This Looks Like in Practice

👉 ILLUSTRATIVE EXAMPLE

A mid-sized industrial controls manufacturer assumed its CRA exposure was limited to two current product lines. A structured inventory exercise turned up eleven additional SKUs still active in distributor channels across three EU member states, including a discontinued gateway device still receiving security patches under a legacy support contract. None of the eleven had been through a classification review; two turned out to sit in Important Class I, changing which conformity route and documentation depth applied. A dry run of the reporting pathway surfaced a second, separate gap: nobody in the organisation had been assigned to actually receive and triage a Single Reporting Platform notification once one arrived. Both gaps were fixable within six weeks once identified — the expensive part wasn’t the fix, it was not knowing the gaps existed until someone looked for them.

“A checklist isn’t evidence. A rehearsed reporting pathway is.”

How VISTA InfoSec Turns This Into a Tested Readiness Record

VISTA InfoSec’s CRA gap assessments follow the same practitioner-led, evidence-based methodology behind our other regulatory engagements, run in three phases:

1. Inventory & Classification

Build or validate your product inventory and confirm classification against Annex III and IV, including legacy and white-labelled SKUs.

2. Documentation & Reporting Dry-Run

Audit technical documentation against the retention standard and rehearse the Single Reporting Platform pathway end to end.

3. Remediation Roadmap

A prioritised remediation roadmap that names owners and dates, ahead of the September 2026 reporting deadline.

KEY TAKEAWAYS

✓  Article 14 reporting duties start 11 September 2026 — over a year before the CRA’s full application in December 2027
✓  There’s no grandfather clause — legacy products already on the EU market are in scope
✓  Classification (Default / Important I / Important II / Critical) gates the conformity route and documentation depth
✓  Article 21 obligations can shift onto an importer or distributor who rebrands or substantially modifies a product
✓  A checklist isn’t evidence — a rehearsed Single Reporting Platform dry-run is what an assessor actually credits

Frequently Asked Questions

What is an EU Cyber Resilience Act gap assessment?
It’s a structured review that compares an organisation’s current product inventory, classification, documentation, and incident-reporting capability against the CRA’s requirements, starting with the Article 14 reporting obligations that apply from 11 September 2026.
Does the CRA apply to products already on the market?
Yes. There is no grandfather clause. Legacy products already placed on the EU market are in scope for the reporting obligations that begin in September 2026, and for the broader requirements that apply from December 2027.
What’s the difference between Article 14 and Article 13 of the CRA?
Article 14 covers the reporting duties for actively exploited vulnerabilities and severe incidents, effective 11 September 2026. Article 13 covers the broader process obligations for products placed on the market, which take full effect in December 2027. Confusing the two leads either to under-preparing for the reporting deadline or building processes the organisation doesn’t need yet.
Who is responsible for reporting: the manufacturer, importer, or distributor?
Generally the manufacturer, under Article 14. But under Article 21, an importer or distributor that places a product under its own name or trademark, or substantially modifies it, takes on the full set of manufacturer obligations, including reporting.
How long does technical documentation need to be retained?
Ten years, or the length of the product’s support period, whichever is longer.
When should a manufacturer start its CRA gap assessment?
Now. The reporting clock starts on 11 September 2026 for actively exploited vulnerabilities and severe incidents; a gap assessment is what determines whether an organisation can actually meet the 24-hour and 72-hour deadlines once that clock is running.

The Bottom Line

The organisations that come through the first CRA enforcement wave cleanly are the ones treating this gap assessment as infrastructure, not paperwork: inventorying what they actually ship, classifying it honestly, and rehearsing the reporting pathway before a real vulnerability forces the question. An inventory can be built in weeks; fixing gaps found during a real incident takes a lot longer, and it happens under a 24-hour clock instead of on your own schedule.

VISTA InfoSec • EU Cyber Resilience Act Compliance Specialists

Still Treating CRA Reporting as a 2027 Problem?

The reporting clock starts 11 September 2026. VISTA InfoSec’s CRA Gap Assessment covers inventory, classification, documentation, and reporting readiness together — so you know exactly where you stand while fixing gaps is still cheap.

 

Explore CRA Compliance Services → Book Your Free 40-Minute Consultation

 

The post EU CRA Gap Assessment: Are You Ready for 2026? appeared first on Information Security Consulting Company - VISTA InfoSec.

EU Cyber Resilience Act Gap Assessment:Key Areas to Review Before the September 2026 Deadline

✇VISTA InfoSec
By: Narendra Sahoo
22 July 2026 at 07:05
Rate this post

Last Updated on July 22, 2026 by Narendra Sahoo

Most compliance teams have filed the EU Cyber Resilience Act under “2027” — the date the regulation becomes fully applicable. That’s the wrong filing date. From 11 September 2026, manufacturers must already report actively exploited vulnerabilities and severe incidents affecting products with digital elements, more than a year before the rest of the regulation takes effect. This guide covers the four areas a CRA gap assessment needs to test before that clock starts — inventory, classification, documentation, and the reporting pathway itself — current as of July 2026.

11 Sept 2026
Article 14 reporting obligations go live — no grandfather clause
24 Hrs
Early-warning deadline once a qualifying event is discovered
€15M / 2.5%
Top fine tier — whichever of the two is higher
4 Tiers
Default, Important Class I & II, Critical — by function, not name

1⃣ The Deadline That Arrives Before the CRA Is Even Fully in Force

A gap assessment run today has to answer a narrower, more urgent question than full CRA readiness: can this organisation detect, assess, and report a qualifying event within 24 hours, starting in September 2026? That’s a different deliverable than a multi-year compliance roadmap, and most manufacturers haven’t built it yet. The reporting clock is unforgiving once triggered — an early warning within 24 hours, a fuller notification within 72 hours, and a final report no later than fourteen days after a fix is available for vulnerabilities, or within one month for severe incidents.

💡 CRITICAL INSIGHT

These obligations apply to every in-scope product already on the EU market, including legacy products placed there long before the CRA existed. There is no grandfather clause — a product shipped in 2019 is in scope for a report filed in 2026 if it’s still in the field.

2⃣ Build the Product Inventory First

Nothing else in a gap assessment works without an accurate product inventory. It should cover new and legacy products, software and hardware, embedded components, remote data processing solutions, supported versions, and unsupported versions still in use. Most manufacturers underestimate this step: a portfolio review frequently turns up products nobody remembers actively shipping, white-labelled variants sold under a partner’s brand, and components inherited through acquisitions that were never reassessed. A product list alone isn’t enough — manufacturers also need to identify the responsible legal entity behind each product, since which national CSIRT receives a given report depends on correctly identifying the manufacturer’s main establishment.

✅ INVENTORY CHECKLIST

□  List every in-scope product, including legacy and unsupported versions still in the field
□  Flag white-labelled variants and components inherited through acquisitions
□  Map each product to the legal entity that qualifies as its manufacturer

Not sure your product inventory is actually complete?

VISTA InfoSec’s CRA compliance consultants build or validate your full product inventory and confirm which entity is the legal manufacturer for each item — before a regulator asks first.

Explore CRA Compliance Services →

3⃣ Classify Every Product Against Annex III

Once the inventory exists, every product needs a classification call: Default, Important Class I, Important Class II, or Critical, based on its core functionality rather than its name or marketing description. Skipping classification at the gap-assessment stage is the most common shortcut, and the most expensive one — the tier determines which conformity assessment module applies, which standards are relevant, and how deep the technical documentation needs to go.

Tier What It Covers Representative Examples Conformity Route
Default Everything not named in Annex III or IV Most general-purpose software and connected devices without elevated security functions Manufacturer self-assessment
Important – Class I Security-adjacent functions, moderate risk Password managers, VPN clients, identity/access management software, smart locks, cameras, baby monitors, connected toys Self-assessment against harmonised standards, or third-party review
Important – Class II Higher-risk security infrastructure Firewalls, intrusion detection/prevention systems, hypervisors, tamper-resistant microprocessors Mandatory third-party (notified body) assessment
Critical Foundational trust infrastructure Hardware security modules, smart cards and readers, tamper-resistant secure elements, smart meter gateways Mandatory third-party assessment; may require EU cybersecurity certification

Annex III and IV category definitions have been refined through 2025–26 implementing guidance — confirm current status against the latest published list before finalising a classification.

4⃣ Importer and Distributor Obligations Under Articles 20 and 21

Article 20 sets out importers’ general obligations: confirming that the manufacturer has met the product-related essential requirements, that vulnerability-handling processes exist, that the conformity assessment was properly carried out, and that technical documentation has been drawn up before a product carries the CE marking. Article 21 covers a narrower and easily missed case — when an importer or distributor places a product under its own name or trademark, or substantially modifies a product already on the market. At that point, the importer or distributor takes on the full set of manufacturer obligations, including the Article 14 reporting duties.

👉 IN PRACTICE — A WHITE-LABEL DISTRIBUTION DEAL

A distributor rebrands a connected sensor under its own trademark for a regional market. On paper, the original OEM is still “the manufacturer.” Under Article 21, it’s the distributor’s name on the box that now carries the Article 14 reporting duty — a gap assessment that only reviews the OEM’s side of this chain leaves that distributor’s exposure completely unmapped.

5⃣ Technical Documentation — Where the Backlog Usually Is

Technical documentation is where most gap assessments find their largest volume of unfinished work. The manufacturer must perform a cybersecurity risk assessment that informs how the essential requirements are implemented, and that risk assessment — along with the standards or measures chosen to meet those requirements — has to be part of the technical documentation itself, not held separately in someone’s inbox. Retention isn’t a minor footnote either: records must be kept for ten years or the product’s support period, whichever is longer. Organisations with an existing ISO 27001-aligned documentation practice usually find this easier — the record-keeping discipline transfers directly, even though the two frameworks serve different purposes.

Third-party components add a second layer: a manufacturer must exercise due diligence to confirm those components don’t compromise the finished product’s cybersecurity. This is where inventories fall short most often — software bills of materials are frequently incomplete or exist only for top-level dependencies, and due-diligence evidence for embedded components is often unwritten institutional knowledge rather than a documented control tied to a standard format like CycloneDX or SPDX.

✅ DOCUMENTATION CHECKLIST

□  Confirm the risk assessment lives inside the technical file, not a separate inbox
□  Test whether documentation formats can survive the ten-year retention window
□  Build or complete an SBOM in a standard format (CycloneDX/SPDX) for every product

Want your documentation retention-tested before an auditor does it for you?

Book a free 40-minute consultation with VISTA InfoSec to walk through your current technical documentation against the CRA’s ten-year retention standard.

Book Your Free 40-Minute Consultation →

6⃣ Pressure-Test the Reporting Pathway Itself

Knowing the rules isn’t the same as being able to execute them under a 24-hour clock. A gap assessment should map the relevant Single Reporting Platform route: determine the manufacturer’s main establishment for Article 14(7) purposes, identify the fallback route for non-EU manufacturers, and confirm which national CSIRT acts as coordinator. ENISA has indicated the platform will be operational by 11 September 2026, with a testing period beforehand — which makes a dry run, not just a policy document, the real test of readiness.

T0
Event Detected
24 HRS
Early Warning
72 HRS
Notification
14 DAYS / 1 MO.
Final Report

⚠ DON’T CONFUSE THESE TWO CLOCKS

Article 14‘s reporting duties start on 11 September 2026; Article 13‘s broader process requirements for products placed on the market don’t take full effect until December 2027. A gap assessment that confuses the two risks either under-preparing for the reporting deadline or over-building processes the organisation doesn’t need yet — both are avoidable with a clear read of which article applies when.

7⃣ Supply Chain and Contract Language

Supplier relationships are the part of a gap assessment most likely to get skipped, and they carry real exposure. Supplier contracts should be updated to reflect CRA obligations, with CRA compliance built into supplier due-diligence procedures. Suppliers of critical components that could affect a manufacturer’s ability to comply by December 2027 should be prioritised for review now. If your supply chain also touches essential or important entities under NIS2, the two due-diligence exercises overlap enough to run as one review rather than two.

Haven’t reviewed your supplier contracts for CRA exposure yet?

VISTA InfoSec reviews supplier and OEM contracts for CRA-relevant due-diligence and notification clauses, prioritising critical-component suppliers first.

Explore CRA Compliance Services →

8⃣ The Six-Point CRA Readiness Checklist

✅ FULL READINESS CHECKLIST

□  Inventory every in-scope product — new, legacy, supported, unsupported — and confirm the legal manufacturer for each
□  Classify each product as Default, Important Class I, Important Class II, or Critical
□  Map the Article 20/21 chain of manufacturer, importer, and distributor obligations
□  Audit technical documentation against the ten-year retention requirement
□  Dry-run the Single Reporting Platform pathway, including the 24-hour and 72-hour clocks
□  Review supplier contracts for CRA-relevant due-diligence and notification clauses

9⃣ What This Looks Like in Practice

👉 ILLUSTRATIVE EXAMPLE

A mid-sized industrial controls manufacturer assumed its CRA exposure was limited to two current product lines. A structured inventory exercise turned up eleven additional SKUs still active in distributor channels across three EU member states, including a discontinued gateway device still receiving security patches under a legacy support contract. None of the eleven had been through a classification review; two turned out to sit in Important Class I, changing which conformity route and documentation depth applied. A dry run of the reporting pathway surfaced a second, separate gap: nobody in the organisation had been assigned to actually receive and triage a Single Reporting Platform notification once one arrived. Both gaps were fixable within six weeks once identified — the expensive part wasn’t the fix, it was not knowing the gaps existed until someone looked for them.

“A checklist isn’t evidence. A rehearsed reporting pathway is.”

How VISTA InfoSec Turns This Into a Tested Readiness Record

VISTA InfoSec’s CRA gap assessments follow the same practitioner-led, evidence-based methodology behind our other regulatory engagements, run in three phases:

1. Inventory & Classification

Build or validate your product inventory and confirm classification against Annex III and IV, including legacy and white-labelled SKUs.

2. Documentation & Reporting Dry-Run

Audit technical documentation against the retention standard and rehearse the Single Reporting Platform pathway end to end.

3. Remediation Roadmap

A prioritised remediation roadmap that names owners and dates, ahead of the September 2026 reporting deadline.

KEY TAKEAWAYS

✓  Article 14 reporting duties start 11 September 2026 — over a year before the CRA’s full application in December 2027
✓  There’s no grandfather clause — legacy products already on the EU market are in scope
✓  Classification (Default / Important I / Important II / Critical) gates the conformity route and documentation depth
✓  Article 21 obligations can shift onto an importer or distributor who rebrands or substantially modifies a product
✓  A checklist isn’t evidence — a rehearsed Single Reporting Platform dry-run is what an assessor actually credits

Frequently Asked Questions

What is an EU Cyber Resilience Act gap assessment?
It’s a structured review that compares an organisation’s current product inventory, classification, documentation, and incident-reporting capability against the CRA’s requirements, starting with the Article 14 reporting obligations that apply from 11 September 2026.
Does the CRA apply to products already on the market?
Yes. There is no grandfather clause. Legacy products already placed on the EU market are in scope for the reporting obligations that begin in September 2026, and for the broader requirements that apply from December 2027.
What’s the difference between Article 14 and Article 13 of the CRA?
Article 14 covers the reporting duties for actively exploited vulnerabilities and severe incidents, effective 11 September 2026. Article 13 covers the broader process obligations for products placed on the market, which take full effect in December 2027. Confusing the two leads either to under-preparing for the reporting deadline or building processes the organisation doesn’t need yet.
Who is responsible for reporting: the manufacturer, importer, or distributor?
Generally the manufacturer, under Article 14. But under Article 21, an importer or distributor that places a product under its own name or trademark, or substantially modifies it, takes on the full set of manufacturer obligations, including reporting.
How long does technical documentation need to be retained?
Ten years, or the length of the product’s support period, whichever is longer.
When should a manufacturer start its CRA gap assessment?
Now. The reporting clock starts on 11 September 2026 for actively exploited vulnerabilities and severe incidents; a gap assessment is what determines whether an organisation can actually meet the 24-hour and 72-hour deadlines once that clock is running.

The Bottom Line

The organisations that come through the first CRA enforcement wave cleanly are the ones treating this gap assessment as infrastructure, not paperwork: inventorying what they actually ship, classifying it honestly, and rehearsing the reporting pathway before a real vulnerability forces the question. An inventory can be built in weeks; fixing gaps found during a real incident takes a lot longer, and it happens under a 24-hour clock instead of on your own schedule.

VISTA InfoSec • EU Cyber Resilience Act Compliance Specialists

Still Treating CRA Reporting as a 2027 Problem?

The reporting clock starts 11 September 2026. VISTA InfoSec’s CRA Gap Assessment covers inventory, classification, documentation, and reporting readiness together — so you know exactly where you stand while fixing gaps is still cheap.

 

Explore CRA Compliance Services → Book Your Free 40-Minute Consultation

 

The post EU Cyber Resilience Act Gap Assessment:Key Areas to Review Before the September 2026 Deadline appeared first on Information Security Consulting Company - VISTA InfoSec.

❌
❌