CRA Consulting Framework: How to Meet the September 2026 and December 2027 Deadlines

Two tracks aligned to the two CRA deadlines

CRA compliance can be organized into six modules that follow the logical sequence the regulation requires. Those modules fall into two tracks, each aligned with one of the CRA's compliance deadlines.

Track A addresses the September 2026 vulnerability reporting deadline. It covers product scoping and the implementation of vulnerability reporting processes. This work can start immediately and should be completed well before the deadline, because September 2026 is the date from which reporting obligations apply, not a preparation milestone.

Track B prepares the organization for full compliance by December 2027. It covers intended purpose definition, risk assessment, gap analysis, and the implementation roadmap. This work should be executed during 2026 to leave sufficient time to put the necessary technical and organizational measures in place before the deadline.

Track A and Track B can run in parallel.

Track A: 2026 CRA vulnerability reporting readiness

Module 1: Product and RDPS scoping

The starting point is knowing which of your products and services fall under the CRA. This module reviews the product inventory, evaluates exclusions against the CRA's Article 2 exemptions, and classifies each product as default, Important (Class I or II), or Critical based on Annexes III and IV. It also reviews the remote data processing services tied to affected products.

The output is a product inventory with a CRA scope determination per product, an exclusion assessment with regulatory justification, and a product classification report that includes RDPS mapping. This module has no dependencies and is the starting point for all the others.

The value is straightforward. You invest compliance effort only where it is legally required, because you know exactly which products and RDPS services fall under the regulation.

Module 2: Vulnerability reporting implementation

This module builds the capability to meet the September 2026 reporting obligations. It is structured into three sub-modules that build on each other.

The first reviews your existing vulnerability awareness and incident response setup and performs a gap analysis against both the 2026 and 2027 requirements. The second defines the triage process, including evidence thresholds, decision authority, escalation paths, a severity assessment methodology aligned to the Article 14(2) reporting content requirements, and handoff points between security, product, and legal teams. The third defines the reporting workflow itself: the staged process for vulnerabilities (24 hours, 72 hours, 14 days) and incidents (24 hours, 72 hours, one month), the user notification process under Article 14(8), and submission to the ENISA Single Reporting Platform (SRP), along with a technical concept for automated reporting.

Deliverables include a current state assessment, a gap analysis covering both deadlines, triage process documentation, a RACI matrix, workflow and technical architecture documentation, and reporting templates for each stage. This module depends on Module 1, so you know which products require vulnerability reporting.

The value is operational readiness. Clear processes, defined roles, and the right tools mean your teams do not miss a reporting deadline.

Track B: 2027 full CRA compliance preparation

Module 3: Intended purpose definition

A clear definition of intended purpose is the foundation for everything that follows in Track B. This module defines a product's core and support functions, its acceptable contexts, and its conditions of use, and it documents these per product or product family using a reusable template.

The value is control over liability. When you define clearly what your product is designed to do and where its boundaries are, you control what you are liable for. This module depends on Module 1 to identify which products require intended purpose documentation.

Module 4: Risk assessment

The risk assessment must be grounded in the defined intended purpose, which is why it depends on Module 3. This module defines a risk assessment methodology based on industry, product category, and individual needs, analyzes cybersecurity risks across the full product lifecycle, and determines which Annex I requirements apply and to what degree. It also defines a process for keeping the risk assessment current over the lifecycle.

Deliverables include the methodology document, product-level risk assessment reports, an Annex I applicability mapping per product, and a lifecycle process for updates.

The value is accuracy of scope. You know what applies to you and what does not, which avoids both overengineering and blind spots.

Module 5: Gap analysis

This module measures your current state against the Annex I requirements: the 13 security property requirements in Part I and the 8 vulnerability handling requirements in Part II. It also evaluates supply chain and third-party component coverage, identifies the applicable standards for your industry and product category, and assesses conformity assessment readiness.

Deliverables include a gap analysis report per product or product family, a standards applicability assessment, a conformity assessment readiness evaluation, and a prioritized gap register with severity ratings. This module depends on Module 4 to determine which requirements apply and at what level.

The value is certainty. You know exactly where you stand today, with no guesswork.

Module 6: Implementation roadmap

The final module turns the gap register into an actionable plan. It identifies viable implementation options for each gap, evaluates each against implementation complexity and maturity fit, calculates total cost of ownership over the product lifecycle, and consolidates the selected options into an integrated roadmap with milestones toward December 2027.

Deliverables include an options analysis per gap with complexity, maturity, and TCO comparison, a recommended implementation path per product or product family, and the integrated roadmap. This module depends on Module 5, which provides the gap register that drives the options analysis.

The value is economic. You find the smartest way to get compliant, which is not necessarily the fastest or cheapest, but the one that makes sense over the long run.

How to engage

The modular structure means you can engage in the way that fits your situation.

A full programme delivers all six modules in sequence across both tracks, which suits organizations beginning their CRA compliance journey and needing end-to-end support from scoping through implementation planning.

A track-based engagement lets you take Track A (Modules 1 and 2) and Track B (Modules 3 through 6) independently, which suits organizations that need to prioritize the September 2026 deadline while planning the broader effort separately.

Individual modules can be engaged where prior steps are already complete internally, provided the module dependencies are satisfied either through a preceding module or through equivalent documentation you provide.

Indicative timeline

Actual timelines depend on the number of products and product families in scope, the complexity of the portfolio, and the maturity of existing processes and documentation. The durations below are indicative.

Because Track A and Track B can run in parallel, a full programme covering all six modules typically takes 4 to 7 months, depending on portfolio complexity.

Why a modular approach fits the CRA

CRA compliance is a risk-based exercise, not a checklist. The modular sequence reflects that. Each module produces a defined output that grounds the next, so the effort stays proportionate to what the regulation actually requires for your products.

Ready to start your CRA compliance journey? Discover Tributech's CRA consulting paths and find the right starting point for your organization. Explore CRA offerings.

The approach also recognizes that the CRA does not exist in isolation. It sits alongside the Data Act, the AI Act, the ESPR, and other regulations for digital products. Treating these together, rather than in silos, allows for integrated compliance strategies that address the full regulatory landscape rather than each regulation on its own.

Tributech contributes directly to the standards that will define CRA compliance. Patrick Lamplmair, Tributech's CTO, is a member of the CRA standardisation committee JTC 13 via Austrian Standards, which gives early insight into emerging requirements and interpretations. Because Tributech also develops its own products, the perspective spans requirements translation through to technical implementation, which means vendor-neutral support grounded in the practical experience of building compliant products.