CRA readiness and gap assessment: what to check first

What a Cyber Resilience Act readiness and gap assessment covers before December 2027

A CRA gap assessment compares your products, risk assessment, technical documentation and vulnerability handling against the Annex I essential cybersecurity requirements and the duties in Articles 13 and 14, then produces a prioritized plan of what to fix, document or justify. It answers a narrower question than certification: where each product stands today and what must change before the regulation applies in full on 11 December 2027. Your customer, contract or regulator may be asking now because the Article 14 reporting duty already applies, following 11 September 2026, to in-scope products regardless of when they were placed on the market. The answer differs by organization. The number of products matters, and so does how many are already on the EU market, since products placed there before 11 December 2027 fall under the regulation only if they are substantially modified from that date. Your role matters too. A manufacturer carries the full set of duties, while an importer or distributor must check that the product carries the required documentation and conformity marking before it is sold. Start by confirming which products are in scope, which role you hold for each, and which products you expect to change substantially before the deadline.

The organization owns its controls and the decisions about them. An implementation partner can prepare systems, documentation, vulnerability handling processes and evidence, and can test the gaps the assessment finds. Only an independent conformity assessment body or a notified body issues a report or certificate, and only where the chosen route requires one. Ask any provider to state in writing which parts of the work are advisory, which are engineering, and which are reserved for an independent body. Treat a provider that offers a CRA certificate on its own authority as a warning sign. For each product, the CRA gap assessment should record the current risk assessment, whether it is documented and updated during the support period, each Annex I Part I requirement with a statement of whether it applies and how it is met, and any requirement you judge not to apply, with the justification that Article 13(4) requires in the technical documentation. Confirm with the Commission's guidance, which is non-binding, whether existing measures on older products still address current risks, since a current risk assessment may show that redesign is not needed. Ask the assessment provider to show how each finding maps to a named owner and a dated action.

What to check first when reporting already applies

The sequence confirms which reporting duties already bind your products, sets up the route for notifications, and builds the product records that every later readiness decision depends on. Durations for each phase should be confirmed in the written scope before work starts.

Confirm the Article 14 duty for each product
Establish, product by product, that the Article 14 reporting obligation applies to every in-scope product, including products placed on the market before 11 December 2027. The reporting duty attaches whenever a product was placed on the market, so the date of first placement does not remove it. Legal or compliance leads own this check, with engineering input on which products are in scope. The output is a short scope memo that lists each in-scope product and confirms its reporting duty, reviewed against the Article 14 text.
Identify the CSIRT and reporting route
Determine which CSIRT is designated as coordinator for your organization and confirm how notifications reach it through ENISA's Single Reporting Platform, which began initial operating capability on 11 September 2026. Confirm the account setup, who holds credentials, and how notifications are made available to ENISA at the same time. Ask the relevant authority or ENISA's published FAQs to confirm any national specifics. The output is a confirmed reporting route with named accounts and contacts.
Build the internal triage and escalation process
Define how a suspected actively exploited vulnerability or severe incident moves from the engineering or support team to the person who decides on notification. Set who classifies the event, who signs off the notification, who holds the timing obligations, and how third-party component issues are routed to the supplier. Test the process with a tabletop exercise using an illustrative scenario before it is relied on. The output is a reporting runbook with roles, decision points and evidence capture steps.
Inventory every product and version in scope
Compile a register of all products with digital elements that you make available, import or distribute, including hardware, standalone software, and cloud or remote data processing components where they form part of a product. Include legacy products still in use and products from acquired businesses. Owners should be named for each entry. The output is a product register that serves as the single source for scope, classification and reporting decisions, and it is complete when engineering and product management have each signed off on their portion.
Classify each product by scope and category
For each product in the register, record whether it falls within scope, whether any sector exclusion applies, and whether its core functionality places it in the default category or in the important or critical categories set by Annex III or Annex IV. The technical descriptions in Commission Implementing Regulation (EU) 2025/2392 help confirm category placement. Classification drives the conformity assessment route, so record the reasoning alongside the result. The output is a classification record for each product, reviewed by someone outside the product team.
Record placed-on-market dates per product and build variant
For each product, record the date its standalone software version or hardware model was first placed on the market, and separate build variants that carry different components or features. Updates that are not substantial modifications do not change that first placement date, so the record should show the original date and any later changes. Compliance and product operations own this record, with release engineering supplying the version history. The output is a placement register that shows, for each product and variant, when the regulation's dates begin to matter.
Identify products that will be substantially modified
Review the roadmap for each product and flag changes planned after 11 December 2027 that could amount to a substantial modification. Products placed on the market before that date fall under the regulation only if they are substantially modified from that date, so this flag determines which legacy products come into full scope. Product, legal and security leads should review the flags together, using the Commission's examples as a reference. The output is a modification forecast that feeds the gap assessment and the timing plan for each product family.

How to document the risk assessment and justify requirements that do not apply

Article 13(3) asks manufacturers to document a risk assessment for each product and keep it current for the whole support period. The assessment has to start from the product's intended purpose, the use that can reasonably be foreseen and the conditions under which the product is used, not from a generic threat list. It must also state, for each property in Annex I Part I point (2), whether that requirement applies to the product and how the product implements it. For a readiness project, the practical output is a matrix with one row per point (2)(a) to (m) and the general requirement, each showing applicability, the implemented measure, the component or configuration that carries it and the evidence that proves it. Ask your engineering leads to name the owner of each row. A risk assessment that nobody is responsible for updating will be out of date by the first release that changes the attack surface.

Article 13(4) goes further. Where an essential requirement does not apply to a product, the technical documentation must contain a clear justification for that conclusion. An assessor will read a bare statement such as "not applicable, no relevant functionality" as an unsupported claim. A stronger justification ties the exclusion to a specific fact about the product. Illustrative example: a headless telemetry gateway that is only reachable through a locked-down private network and has no user interface, no removable media interface and no local accounts may have a reasoned case for not implementing a requirement aimed at those features, but only if the documentation names the interfaces it has, shows that the excluded feature is absent from the build, and records how that conclusion will be rechecked when the architecture or intended purpose changes. Confirm each exclusion against the actual build and interface list, and do not let the exclusion outlive a design change that adds the feature back.

Which existing products need work and which may not

Existing products do not all face the same deadline. Whether a product needs redesign, a new conformity route or only reporting readiness depends on when it was placed on the market, whether it has been substantially modified and whether its support period is still running. Use these categories to sort your portfolio before you commit engineering effort.

Placed before December 2027, unmodified

Products already on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. Their Article 14 reporting duty still applies whenever they were placed on the market, so the Article 14 duty is the obligation to check first. Confirm that you can identify affected products, their vulnerabilities and the CSIRT you would notify. Part II vulnerability handling does not apply to them under guidance section 9.1, but reporting does.

Designed before, placed after

Products designed before 11 December 2027 but placed on the market afterwards need not be redesigned if a current risk assessment shows that existing measures adequately address the risks (guidance section 2.7). The work is evidence-driven: a documented, up-to-date risk assessment that maps existing controls to the Annex I Part I requirements and states how each one is implemented. Gaps found in that review decide whether targeted changes are needed.

Substantially modified after December 2027

A product that is substantially modified after 11 December 2027 is treated as a new product for compliance purposes, which means full reassessment. That covers the risk assessment, Annex I Part I requirements, Part II vulnerability handling, technical documentation, conformity assessment and the EU declaration of conformity. Track planned major releases, architecture changes and new interfaces against the substantial modification test so you can see which releases trigger this path before they ship.

Support period ended

Once a product's support period ends, Part II vulnerability handling no longer applies (guidance section 9.1), but Article 14 reporting continues. You still have to report actively exploited vulnerabilities and severe incidents for products you placed on the market. Check whether each retired product still has a named contact, monitoring for component vulnerabilities and a process to file reports, because end-of-life status does not remove the reporting duty.

Build variants with different components

Build variants that carry different components or features are separate products under guidance section 2.1, and each needs its own assessment. Product variants that share architecture, security-relevant design, intended purpose and risks can share one risk assessment and one technical file under section 7.4, but differences in interfaces, software stacks or update mechanisms must be reflected. Inventory variants against their bills of materials before you group them.

Legacy products with no security owner

Legacy products often have no named security owner, no current SBOM and no record of past vulnerability handling. Assign ownership before any assessment starts, then build the component inventory, collect vulnerability history and decide whether the product is still supported. Ask the engineering lead who can answer for the code, the third-party components and the update channel. Without an owner, the risk assessment cannot be documented or kept current during the support period.

Grouping product families: one assessment or one per build

This table compares three ways to organize CRA assessments across product variants and builds. Read each row against your architecture records, because the grouping you choose determines how many risk assessments, technical files and declarations you maintain. The main takeaway is that sharing one assessment is only defensible when variants truly share architecture, security-relevant design, intended purpose and risks.

Option	When it fits	What must still be reflected per variant	Main risk of choosing it
One assessment per product family	Variants share architecture, security-relevant design, intended purpose and risks, as described in guidance section 7.4	Differences in interfaces, software stacks or update mechanisms must still be recorded within the shared documentation	Over-grouping hides a variant with different risks, so one flawed variant can invalidate the shared file
Separate assessments for variants that differ technically	Variants differ in interfaces, software stacks or update mechanisms, so shared risks no longer hold	Each variant needs its own risk assessment, technical documentation and conformity route entry reflecting those differences	Higher maintenance load, and a shared template can drift away from the actual variant configuration
Separate assessments per build variant	Builds carry different components or features, which the Commission treats as separate products under guidance section 2.1	Each build needs its own documentation, declaration and component list, including its SBOM	Largest effort, and an unnoticed feature flag or component change can create an undocumented product
Single product with documented configurations	Only minor configuration options differ and the security-relevant design is unchanged	Configuration options and their security effects should be listed and tested against the same risk assessment	Assessors may question whether the options are truly configuration rather than separate products

How standards timing changes the readiness plan

The horizontal standard on designing, developing and producing products with an appropriate level of cybersecurity based on the risks was due from the European standardization organizations by 30 August 2026, according to the Commission's FAQ 6.10. This is the standard that most closely matches the risk-based development work your teams already need to document, so it should anchor your gap assessment. Because the deadline has passed, the first question is not whether a draft exists but whether the final text has been published in the Official Journal and which version applies to your product.

Confirm publication status: Check the Commission's CRA pages and the European standardization organizations' records to see whether the standard is cited as a harmonized standard.
Record the version: Note the exact edition you mapped against, because a later revision may change the controls you claim to meet.
Map your controls: Link each step of your secure development lifecycle to the standard's requirements and identify gaps in evidence.
Document deviations: Where you depart from the standard, explain in your technical documentation how your approach still addresses the risks.
Plan for updates: Assign an owner to track amendments so your risk assessment stays current during the support period.

Before you plan any assessment, confirm the current status of this deliverable in the Commission's sources.

What must be in place before the assessment starts

An assessor or notified body will not start by reading your product. They will start by asking whether the records that describe it exist, are current and agree with each other. The six checks below are the ones to close first, because every later decision about gaps depends on them.

Current risk assessment

Your risk assessment must analyze risks from the product's intended purpose, reasonably foreseeable use and conditions of use, and it must be updated during the support period. Internally, check that the assessment names the version and date it covers, and that a recent change such as a new interface or update mechanism has been reviewed against it. Pull the signed assessment, its revision history and the change tickets that triggered each review.

Requirement-by-requirement technical documentation

The technical documentation should state, for each Annex I Part I point (2) requirement, whether it applies and how it is implemented. Check that each statement points to a real control, configuration or design document, not to a general policy. Pull the requirement mapping, the design documents it cites and the test results that show each implemented measure works.

Product register with market dates

A product register lists every product, version and build variant with the date each was first placed on the EU market. These dates decide whether a product is in scope under the transition rules and whether a later change counts as a substantial modification. Internally, confirm that variants with different components or features appear as separate entries. Pull the register, release records and the first-offer date for each standalone software version.

Article 14 reporting route

Reporting to the CSIRT designated as coordinator through ENISA's platform has applied since 11 September 2026 to all in-scope products, whenever they were placed on the market. Check that someone owns the decision to notify, that the 24-hour early warning can be produced on time, and that the route to the correct CSIRT is written down. Pull the procedure, the named roles, the contact list and a recent tabletop exercise record.

Vulnerability handling process

Part II vulnerability handling applies for the support period of products in scope of it, so the process must run continuously rather than as a one-time project. Check that intake, triage, fix, advisory and update steps have named owners, and that the support period for each product is recorded. Pull the handling procedure, the vulnerability log with timestamps and the published advisories for recent cases.

Justifications for non-applicable requirements

Any Annex I essential requirement that does not apply must carry a clear justification in the technical documentation. Assessors check these justifications against the risk assessment, so a claim that a requirement is not relevant must match what the product actually does. Internally, review each exclusion for consistency with the product's interfaces and data handling. Pull the justification record, the risk assessment entries it relies on and the approval date.

Who does what in a CRA readiness assessment

The manufacturer owns the products, the cybersecurity risk assessment and every decision that follows from it. Under the regulation, the manufacturer is the party that must meet the essential requirements, keep the technical documentation and sign the EU declaration of conformity, so these duties cannot be handed to a consultant. Internal teams also decide which requirements apply to each product and must justify any that do not.

Product and risk decisions: Set the intended purpose, reasonably foreseeable use and conditions of use for each product, and own the risk assessment described in Article 13(3).
Justification of exclusions: Record a clear reason in the technical documentation for every Annex I Part I requirement that does not apply, as Article 13(4) requires.
Technical documentation: Keep the documentation current and make it available to authorities for the period the regulation sets, with internal owners named for each section.
Sign-off and declaration: Approve remediation priorities, accept residual risk and sign the EU declaration of conformity once conformity is established.
Usually kept in house: Risk decisions, product scope, accountability for the declaration and day-to-day vulnerability handling.

Before engaging anyone, confirm internal owners for each product family and who holds the signing authority.

What usually delays a CRA readiness project and how to avoid it

Most CRA readiness projects lose time to a handful of avoidable decisions made early: how products are grouped, when reporting duties start, and how the risk assessment is written. Each card names one cause, the step that prevents it, and the evidence an assessor or market surveillance authority will expect to see.

Assessing variants as one product

Teams often write one risk assessment for a product line and assume every build is covered. The Commission guidance allows one set of documentation for variants that share architecture, security-relevant design, intended purpose and risks, but variants that differ in interfaces, software stacks or update mechanisms need those differences reflected. Before grouping, list each build's interfaces, components and update path, and record which differences change the risk picture. Evidence to produce: a variant matrix that ties each product version to its risk assessment entry.

Forgetting the Article 14 reporting duty

The December 2027 date is still ahead, so some organizations plan only for full application. Article 14 reporting has applied since 11 September 2026 to all in-scope products, including those placed on the market earlier. Check now whether your incident response process can file an early warning through ENISA's Single Reporting Platform within the required window. Evidence to produce: a documented reporting procedure, named contacts for the designated CSIRT, and a tested escalation path from engineering to legal.

Writing generic risk assessments

A risk assessment that lists common threats without reference to the product's intended purpose, reasonably foreseeable use and conditions of use will not satisfy Article 13(3). It must also state whether and how each Annex I Part I point (2) requirement applies and is implemented. Where a requirement does not apply, the technical documentation needs a clear justification under Article 13(4). Evidence to produce: a dated, versioned risk assessment tied to specific use cases, with a per-requirement applicability table and written justifications.

Leaving open-source and third-party components out

Inventories built from the company's own repositories miss the open-source libraries, container base images and third-party services that ship with the product. These components are part of what the manufacturer must assess and maintain, so gaps surface late, during documentation or first vulnerability triage. Start with an automated software bill of materials for each build, then review components with no maintainer activity or unclear licenses. Evidence to produce: a machine-generated SBOM per product version, a component owner list, and a record of how each component's vulnerabilities are monitored.

Assuming every pre-2027 product needs redesign

Many teams read the 2027 date as a deadline to rebuild every product already on the market. The guidance says products designed before 11 December 2027 but placed on the market afterwards need not be redesigned if a current risk assessment shows that existing measures adequately address the risks. Substantial modification is the trigger to check. Evidence to produce: a current risk assessment for each legacy product, a gap list of measures that fall short, and a decision record explaining which products need changes and which do not.

Waiting for final standards

Some projects pause until harmonized standards are final before doing any gap analysis. The standardization timetable runs in stages: the horizontal standard on designing and producing with appropriate cybersecurity was due by 30 August 2026, and the standard covering Annex I Part I product properties is due by 30 October 2027. A gap analysis against the regulation's requirements can start now and be updated as standards are published. Evidence to produce: a dated gap assessment mapped to Annex I, with a log of standards to review when each is published.

Questions buyers ask about CRA readiness and gap assessments

Can we run a CRA readiness assessment ourselves?

Yes, an organization can run its own readiness assessment, and many do it first to decide what to outsource. The work is largely internal: listing products, mapping each product to its Annex III or Annex IV category, reviewing the Annex I Part I points against the design, and checking whether the risk assessment and technical documentation exist. Internal teams usually struggle with three things: an honest view of third-party components, a documented justification for every essential requirement that does not apply (Article 13(4)), and an independent view of whether existing measures still address current risks. An outside partner can add that second pair of eyes, but the organization still owns the controls, the risk assessment and the declaration. Confirm with your legal team which person signs off on the classification and the scope.

What do engineering, product and legal teams need to provide?

A readiness assessment needs named people from three functions. Engineering provides architecture diagrams, build and release pipelines, update mechanisms, the software bill of materials where one exists, and records of known vulnerabilities. Product management defines the intended purpose, the conditions of use and the support period for each product, because Article 13(3) ties the risk analysis to those facts. Legal or compliance confirms the market role (manufacturer, importer, distributor or steward), reviews justifications for non-applicable requirements, and tracks which products were placed on the market and when. Ask the partner to name the evidence it expects from each team in writing before work begins, and agree who answers questions within a set window.

How long does a CRA gap assessment take, and what drives it?

The duration depends on the scope, and no fixed duration applies to every organization. The main drivers are the number of products and product families, how many variants each family has, how mature the existing documentation is, and how many third-party and open-source components each product contains. Products with many interfaces, separate build variants or complex update paths take longer, because the Commission guidance treats build variants with different components or features as separate products and requires variant differences to be reflected in the documentation. Ask for a phased plan with the products in scope, the evidence to be reviewed, and the deliverables for each phase, then compare plans against that scope rather than a headline duration.

Is a CRA gap assessment the same as a conformity assessment?

No. A gap assessment is internal preparation that compares a product and its processes with the CRA requirements and lists what is missing. A conformity assessment is the formal procedure a manufacturer follows before placing a product on the EU market, and for some product classes it requires a notified body. Only an independent assessor or certification body can issue a certificate or attestation. DeployOpen prepares systems, controls and evidence for assessments, and it does not issue audit reports, attestations or certifications. A gap assessment helps the organization decide which conformity assessment route applies and what evidence that route will need.

What should a consultant put in a written CRA readiness scope?

A written scope should state, at minimum, the products and product families included, the market role the organization holds for each, and the CRA requirements being assessed. It should list the Annex I Part I points that will be tested and the Part II vulnerability handling processes, and say whether Article 14 reporting readiness is included. It should name the deliverables, such as a classification record, a gap register, a plan for the risk assessment and technical documentation, and a list of evidence gaps. It should state who owns each deliverable, what the organization must provide and by when, what is excluded, and how changes to scope are priced. Also ask whether the consultant will issue any certificate or statement of conformity, which should be no.

Must products sold before 11 December 2027 be redesigned?

Not necessarily. Under Article 69, products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, so they do not need redesign solely to meet the Annex I requirements. The Commission guidance (section 2.7) says products designed before that date but placed on the market afterwards need not be redesigned if a current risk assessment shows that existing measures adequately address the risks. However, Article 14 reporting applies to all in-scope products whenever they were placed on the market, from 11 September 2026. Confirm with counsel how your products are classified and what counts as a substantial modification in your release history.

What changes if we are an importer or distributor?

The core CRA duties sit with the manufacturer, but importers and distributors have their own obligations and must check before they place or make available a product. An importer must verify that the manufacturer has carried out the required procedures and that technical documentation and the EU declaration are in place, and must not place a non-compliant product on the market. A distributor must act with due care and check that the CE marking and declaration accompany the product. An importer or distributor that substantially modifies a product, or places its own name or trademark on it, can take on manufacturer duties. A readiness assessment in these roles focuses on supplier evidence, due diligence records and the process for stopping and reporting non-compliant products. Ask counsel to confirm which role applies to each product line.

How DeployOpen scopes and prepares CRA readiness evidence

DeployOpen helps organizations that run self-hosted open-source platforms inside their own infrastructure check their Cyber Resilience Act position and prepare the technical evidence behind it. We work from the written scope and the products in question, and we do not issue assessments, declarations or certificates. Independent assessors and notified bodies remain responsible for any conformity outcome.

How we scope

Engagements are fixed-scope, with products, environments and deliverables agreed in writing before work starts.
The written scope lists which product families, versions and deployments are included in the readiness review.
We confirm with you which roles you hold, such as manufacturer, importer or steward, before mapping obligations.

How we build

We check the existing risk assessment, technical documentation and update practices against the Annex I requirements in scope.
We identify gaps in evidence, such as missing SBOM output, undocumented support periods or unclear reporting paths.
We prepare the systems and records needed for the gaps, such as vulnerability intake and reporting workflows, within the agreed scope.

How we hand over

You receive a written gap register with each finding, its linked requirement, and the evidence needed to close it.
Documentation covers the justification for any essential requirement that does not apply, written for your technical file.
Your own staff keep ownership of the controls, declarations and any submissions to authorities or ENISA's platform.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial readiness work closes.
Retainers can keep risk assessments current over the support period as products change or standards are published.
Before a quote, ask us to confirm exactly what the retainer covers, including response arrangements and review cycles.