CRA Annex 1 Compliance – Federate, Centralize or Both?

PRODUCT SECURITY BRIEF: Why CRA Annex I fulfilment cannot be left to P&Ls and their engineering departments alone

Annex I obligations attach to the manufacturer, a single legal entity, not to the P&L that happens to build the product. 

When divisions each interpret, implement and evidence Annex I on their own terms, the entity can accumulate several incompatible answers to questions the Regulation expects it to answer once. A market surveillance authority, a notified body or a plaintiff will eventually read those answers side by side.

The recommendations in this article are the result of spending the last year and a half looking at this question. The short answer to the above question is "both". First, we will examine potential failure modes and then take a look out how to best architect the organizational structure to best satisfy the needs of the manufacturer as an entity and the P&Ls within it.

Note: I use the term division to denote P&Ls generally regardless of if they are segmented as divisions or business units.

The requirements through the eyes of the P&L owner

Where I have seen CRA compliance federated, it was rarely an explicit decision. It happened because the Annex I essential requirements read like an engineering specification. Secure boot, update mechanisms, attack surface reduction and SBOMs look like product features, so the work flows to whoever owns the product.

I have watched this play out in multi-division manufacturers over the past 18 months or so. My sample size relatively is small but my experience is the pattern has repeated to an extent. That said, I do not claim the pattern is universal. In each case there was a central office; the problem was that its guidance was ambiguous enough to invite variability from one division to the next. The pull of each division is predictable. Industrial automation gravitates to IEC 62443-4-1 and 4-2. Connected devices gravitate to EN 18031 under the RED delegated act, or to EN 303 645. Mobility divisions with CRA-scope products (EV charging, off-highway and micromobility controllers, since type-approved vehicles sit outside the Regulation) gravitate to ISO/SAE 21434.

At first blush federation seems reasonable. The leverage towards compliance sits in the budgets of the P&L owners, and a central function rarely understands a device well enough to specify its threat model. None of that is wrong. The error is treating Annex I fulfilment as the sum of product decisions, when most of what makes it defensible is a set of entity-level decisions that only look like product decisions.

The obligation has one owner

None of this changes who the Regulation addresses, and it never addresses a division. Article 3(13) defines the manufacturer as the natural or legal person that develops or manufactures the product, or has it developed, and markets it under its name or trademark. Every duty in Article 13 is addressed to that person, and so is every fine.

Two textual features make this more than a formality. First, Annex I Part II is not a set of product properties. Article 13(12) requires conformity of “the processes put in place by the manufacturer” with Part II, and Article 3(31) defines the CE marking as attesting to both the product and those processes. When a division affixes CE under the CRA, it is attesting to the vulnerability handling processes of the legal entity, whether or not it controls them.

Second, the cybersecurity risk assessment is not merely a product artifact. Article 13(3) requires it to state how the manufacturer applies Part I point (1) and the Part II requirements. A risk assessment authored inside a division, in isolation, makes representations about entity-level processes that the division typically does not own.

The penalty structure follows the same path. It attaches to the named manufacturer, not the division. Article 64(2) sets fines for non-compliance with Annex I, Article 13 and Article 14 at up to EUR 15 million or 2.5% of the undertaking’s total worldwide annual turnover, whichever is higher.

Failure mode 1: one manufacturer, several definitions of “appropriate”

Annex I Part I point (1) requires “an appropriate level of cybersecurity based on the risks”. Point (2) then lists thirteen properties that apply “where applicable”, on the basis of the Article 13(2) risk assessment. Article 13(4) requires clear justification in the technical documentation for any requirement treated as not applicable.

That structure delegates enormous interpretive latitude to the manufacturer. Federate it and the latitude gets exercised several times, independently, by people optimizing for their own schedule and BOM cost.

The divergences are not exotic. I have seen protection of data at rest produce sustained disagreement over what needed protecting, with no clear guidance from the central office to settle it. What resolved it was a piloted, common risk assessment process. To get slightly ahead of myself: the central office has to ensure that both the risk assessment process and its scoring scales and acceptance thresholds are common, or divisions will diverge.

The same split can open on risk acceptance thresholds, on what counts as a “known exploitable vulnerability” under point (2)(a) at release, on whether secure-by-default permits a commissioning mode with default credentials, and on logging opt-outs under point (2)(l). Each is a judgement the Regulation leaves to the manufacturer.

The exposure comes through Article 13(22). A market surveillance authority’s reasoned request reaches the entity, not the division, and the entity must produce documentation demonstrating conformity of the product and of the processes put in place by the manufacturer. Authorities may never put two files side by side, and divergence backed by documented differences in intended purpose or compensating controls is defensible. But the burden of justifying it falls on the central office the day one does. An authority that receives two technical files from one manufacturer, applying incompatible applicability logic to the same interface, does not need a harmonized standard to find the weaker one wanting. The stronger file has written the authority’s argument for it.

Failure mode 2: vulnerability handling cannot be divided by org chart

Part II is where federation stops being merely inefficient and starts producing violations. The requirements are written in the singular. Point (5) requires “a policy on coordinated vulnerability disclosure”. Point (6) requires a contact address for reporting. Article 13(17) requires the manufacturer to designate “a single point of contact”. Article 13(9) requires policies and procedures to process vulnerabilities “reported from internal or external sources”.

The deeper problem is that products share code. A multi-division industrial manufacturer typically runs a common RTOS or Linux BSP, a shared bootloader and secure-update stack, a common TLS library, and a fieldbus or OPC UA stack reused across different devices. A vulnerability in any of them is one vulnerability in a dozen products owned by several divisions. The same holds for shared services, core architectures and SDKs used across divisions.

Part II point (1) requires identification and documentation of components, including an SBOM. Divisional SBOM programs produce isolated inventories in toolsets each division owns. The question that matters on day one of an incident, which of our products contain this component, cannot be answered from segregated inventories.

The clock runs on the manufacturer’s knowledge

Article 14 has applied since 11 September 2026. Under Article 14(2)(a), the early warning on an actively exploited vulnerability is due within 24 hours of “the manufacturer becoming aware” of it and must indicate the Member States where the product has been made available. The legal person becomes aware. The Regulation does not wait for the knowledge to travel between divisions.

A conservative reading, and the one I advise clients to adopt, is that the clock starts when reliable evidence of exploitation first reaches anyone in the legal entity. In practice that evidence rarely arrives at a security function first. It arrives through field service, an application engineer, a key-account manager or a customer escalation. A manufacturer that wants to start the clock at its PSIRT has to earn that position with a mandatory internal escalation path, carrying its own SLA measured in hours, from every customer-facing function into PSIRT. Without one, the point of awareness is wherever the evidence first landed.

Article 14(8) then requires the manufacturer to inform impacted users, in a structured machine-readable format where appropriate. Customers buying from three divisions should not receive three advisory formats, three severity scales and three contradictory remediation timelines for one CVE. Part II point (4) imposes the same consistency on public disclosure of fixed vulnerabilities.

Where the notification goes

Article 14(7) routes notifications to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment in the Union, determined by where decisions related to the cybersecurity of its products are predominantly taken. A federated model makes that determination genuinely ambiguous. If each division takes its own product security decisions in a different Member State, the manufacturer has no defensible answer to which CSIRT receives the notification, and it needs that answer before the first 24-hour clock starts, not during it. For manufacturers without a main establishment in the Union, the Regulation cascades the determination to the Member State of the authorised representative and, failing that, of the importer or distributor with the largest number of users. For a group headquartered outside the Union, that cascade is decided by commercial and legal arrangements no single division controls.

Failure mode 3: imputed knowledge and divergent lifetimes

Due diligence

Article 13(5) requires due diligence on third-party components. Article 13(6) requires the manufacturer, on identifying a vulnerability in an integrated component, to report it to the component’s maker or maintainer and remediate it under Part II. Recital 34 makes the scope explicit: Part II applies to the product “in their entirety, including all integrated components”.

This is where federation creates the sharpest exposure. Suppose one division’s due diligence on a supplier’s cellular module finds an exploitable flaw, reports it upstream and ships a mitigation, while another division, sourcing the same module through a different buyer, ships unmitigated. Part I point (2)(a) requires products to be made available on the market without “known exploitable vulnerabilities”. Known to whom? To the manufacturer. The entity knew, because one of its divisions told the supplier in writing.

Divisional due diligence also multiplies the supplier-side burden for no compliance benefit. Each division sends its own questionnaire, negotiates its own notification clause and reaches its own view of the same vendor. That matters doubly in a concentrated supply base, where the upstream supplier is often a single silicon or module vendor serving every division.

Support periods

Article 13(8) requires the support period to reflect expected use time, considering reasonable user expectations, the nature and intended purpose of the product, and the support periods of integrated third-party components providing core functions. It must be at least five years unless the product is expected to be in use for less, and the information used to set it goes into the Annex VII technical documentation.

The Regulation anticipates comparison. Recital 62 has ADCO publishing statistics on average support periods by product category and allows the Commission to set minimums by delegated act where manufacturers “unjustifiably determine different support periods”. Recital 60 notes that industrial control systems are often in use significantly longer than the five-year minimum.

Consider a manufacturer whose controls division declares fifteen years on a device while another division declares five years on a comparable device. It has created an internal comparison authorities will find before ADCO does. Worse, if both run on a shared platform whose end-of-life the platform team sets independently, at least one of those declarations is already unsupportable.

Support period policy is an entity-level decision constrained by shared platform roadmaps. Only a shared decision serves the business and gives a consistent position to anyone who asks. Article 13(10), which requires each security update to remain available for at least ten years after issue or for the remainder of the support period, whichever is longer, also needs one update archive, not several.

Failure mode 4: conformity arguments built from first principles, several times

At the time of writing, no CRA harmonized standard has a reference published in the Official Journal. EN 40000-1-1 (vocabulary) and EN 40000-1-2 (principles for cyber resilience) passed the CEN-CENELEC formal vote, with ratification scheduled for 2 November 2026. EN 40000-1-3 (vulnerability handling) is in the same approval pipeline, and EN 40000-1-4 (generic security requirements) is still in drafting.

Article 27 presumption of conformity is therefore not available to anyone, for now. Every manufacturer is building its conformity argument by mapping Annex I to standards that carry no presumption: IEC 62443-4-1 and 4-2, EN 303 645, EN 18031, ISO/SAE 21434, the EN 40000 drafts. That mapping is the single most consequential exercise in the program. Federated, it gets done per division, and each division’s mapping becomes a separate interpretation of what the manufacturer claims.

The absence of cited standards also has a routing consequence. Under Article 32(2), important products of class I can use internal control only where harmonized standards, common specifications or a European certification scheme have been applied in full. Until then, class I products need notified body involvement, which turns the notified body relationship into a portfolio decision rather than a product one.

The result of per-division mapping is a manufacturer claiming conformity on 62443-4-2 component requirements in one technical file and on EN 303 645 provisions in another, with no common account of which Annex I point each clause satisfies. When OJ references do arrive, Article 13(14) requires the manufacturer to take changes in the referenced standards into account. Under a purely federated approach each division then re-maps separately.

A subtler manifestation is compensating controls applied inconsistently across portfolios. Suppose division A’s controller now declares network segmentation as a compensating control in its intended purpose and user information, while division B’s HMI, routinely deployed in the same cell, assumes none and has historically been installed flat alongside it. The CRA’s reach to reasonably foreseeable use extends to that combination. Mitigating it requires commercial visibility across both portfolios: which installed configurations exist, what customers were told, and which division owns the conversation. No single division has that view.

What should stay federated

None of this argues for a central office that designs products. That model fails faster than federation: it lacks the domain depth to threat-model a drive or a safety controller, and it becomes the schedule bottleneck every division wants to route around. Divisions have roadmap responsibilities well beyond product security, and their priorities will not always align with CRA compliance by December 2027. The central office owns the standard; the divisions can make ROI decisions on which products they sell into the EU. That is where honest conversations about risk against revenue need to happen.

One fact has to frame those conversations: there is no grandfathering of product types. Placing on the market applies to each individual unit, so every unit of a legacy design shipped after 11 December 2027 must meet Annex I. Article 69(2) protects only units already placed before that date, while Article 14 reporting, through Article 69(3), already covers the entire installed base. For each legacy SKU the real choice is to redesign, to stop shipping into the EU, or to plan a last-time-buy ahead of the date.

Time is short. Fourteen months is little time to design or refactor products, and for complex products with long development cycles that window may already have closed. A clean demarcation gives the best results.

Interpretation, process and evidence architecture belong to the manufacturer entity (central). Engineering execution belongs to the P&L divisions (product teams).

The test is simple. If a decision, made differently by two divisions, produces two incompatible statements by the same manufacturer to the same authority, it is central. If it can vary product to product without contradiction, it is federated. The table below sets out how that test resolves for the main decisions.

Decision	Owner	Why
Applicability logic and justification criteria for each Annex I Part I point	Central	Art 13(3)–(4): the manufacturer’s position, read across files
Risk assessment method, artifact templates, scales and acceptance thresholds	Central	Comparable outputs across the portfolio
Threat model, architecture, mitigation selection for a given product	Product team	Requires product depth; varies legitimately
Annex I to standards mapping (62443, EN 303 645, EN 18031, EN 40000 drafts)	Central	One conformity argument; one re-map under Art 13(14)
Applying a vertical standard’s technical requirements in design and test	Product team	Execution against the central mapping
Security technology and methodology acceptance criteria (e.g. approved cryptography)	Central	Part I(2)(e) state of the art; one position on what qualifies, across files
CVD policy, single point of contact, advisory format	Central	Art 13(9), 13(17); Annex I Part II(4)–(6)
Article 14 notification decision and submission	Central	Entity awareness; Art 14(7) main establishment; one CSIRT
Customer-facing escalation path into PSIRT	Central	Defines when the manufacturer “becomes aware”
Triage, fix development and update build for a product	Product team	Engineering work under central SLAs
SBOM format, tooling and cross-product component index	Central	Part II(1); answers “where else is this?”
Supplier due diligence record and notification clauses	Central	Art 13(5)–(6); imputed knowledge
Support period policy and platform end-of-life	Central	Art 13(8); Recital 62 comparability
Support period declaration for a specific product	Product team, within policy	Product-specific use profile
Conformity route and notified body relationship	Central	Art 32; class I routing absent cited hENs; Module H covers the portfolio
Technical documentation content for a product	Product team	Authored to a central structure

IEC 62443-4-1 certification held per development site illustrates the split. It is good evidence that a site executes a secure development lifecycle. It is not evidence that the manufacturer has a coherent position on Annex I, and several site certificates against slightly different interpretations of the same practices do not show that it has one.

The operating model

The failure mode to watch is not the absence of a central function but an advisory one: it publishes guidance, runs training, and has no authority to refuse a technical file or overrule a division’s applicability call. Under the CRA, that is a central function in name only.

Four properties separate a working model from a cosmetic one:

Decision rights, written down. The central office owns the interpretation register: the manufacturer’s documented position on every Annex I point, with applicability criteria and approved justification patterns. Divisions may propose deviations but the central office approves or rejects them, and the register records why. No product reaches an EU declaration of conformity without central office sign-off on its risk assessment against this register.

A reporting line outside the divisional P&L. If the head of the central function reports into a division, every conflict between that division’s ship date and the manufacturer’s exposure is resolved by the party with the ship date. The role should report to the CTO, the general counsel or the chief risk officer, with a direct line to the board on Article 14 events.

One PSIRT front door with federated engineering behind it. A single intake, a single Article 14 decision authority, a single advisory channel and a portfolio-wide component index. Divisional security engineers do triage and fixes under central severity scales and SLAs. The 24-hour decision is made once, by someone who can see every affected product.

Funding that does not depend on divisional goodwill. A running budget allocated on CRA-scope revenue, not a per-request chargeback. A chargeback model lets divisions starve the function at exactly the moment their ship dates are under pressure, which is when its sign-off matters most.

Regulated engineering has run this playbook before. IEC 61508-1 puts functional safety management on the organization, with competence and independence requirements that no single project can satisfy alone. ISO 26262-2 does the same for automotive. The closest precedent is UN Regulation No. 155: the cybersecurity management system is assessed at manufacturer level, and type approval for any vehicle depends on it. The CRA’s drafting is less explicit, but the CE marking’s attestation to “the processes put in place by the manufacturer” imposes the same logic. Organizations that already run an R155 CSMS or a 61508 FSM system should extend that governance pattern rather than invent a new federated one for the CRA.

The relationship

What the central office needs to understand about the divisions. Divisions carry budgets, roadmaps, commercial commitments and development cycles that run months to years. The CRA also imposes specific economics. Annex I Part II requires security updates to be disseminated free of charge, so sustaining-engineering cost over the support period cannot be recovered through paid updates; it has to be priced into the product and its margin model at launch. Central guidance on risk assessment, vulnerability handling and support period policy therefore gates real decisions: funding, lifecycle plans, product cost, development timelines and go-to-market. Divisions need it early enough to build ROI cases for legacy products in the field and for their planned successors, covering roadmap, development priority, budget, support commitments and margin impact. Late guidance is not neutral. It forces those decisions to be made without it.

What the divisions need to understand about the central office. The central office carries ultimate accountability for compliance and for how it is achieved, and it acts for the manufacturer as a legal entity. It owns the consistency of compliance across the entity and the manufacturer’s response under Article 14. In return, divisions must commit standing engineering capacity for triage, remediation and update deployment that is timely and not subject to commercial reprioritization. That is the new normal.

Why the decision cannot wait for December 2027

Article 14 has applied since 11 September 2026 under Article 71(2), and Article 69(3) extends it to products placed on the market before 11 December 2027. Every division’s installed base is already inside the reporting obligation. The PSIRT front door, the customer-facing escalation path, the cross-product component index and the main-establishment determination are needed now, not in fourteen months.

The Annex I design obligations bite on products placed on the market from December 2027. For industrial hardware, many of those products are in architecture and design freeze today. A risk assessment written this quarter inside a division, against that division’s private reading of Annex I, will be the risk assessment in the technical file. Retrofitting a common interpretation onto finished designs costs far more than imposing one before the designs close. For products whose designs or compliance positions are already frozen, a common risk assessment process issued now is what lets the manufacturer assert conformity consistently.

For the central office, the practical sequence is short. Name the accountable executive and the reporting line. Stand up the interpretation register, starting with the points where divisions already disagree. Consolidate PSIRT intake and Article 14 decision authority, and wire every customer-facing function into it. Build the cross-product component index from existing divisional SBOMs. Issue the common risk assessment process so that each division knows where it stands for each of its products. Then let the divisions do what they do best: execute against a common measuring stick.