That changes the conversation fast. Key management stops being an implementation detail and becomes a market-access question. If your product depends on secure updates, authenticated boot, encrypted storage, or trusted device identity, your cryptographic design is no longer something you tidy up later. It sits directly inside your conformity story.

Many teams I advise don’t fail here because they ignore cryptography. They fail because they treat keys as infrastructure plumbing. Under the CRA, that approach doesn’t hold. You need a deliberate system for generation, storage, usage, revocation, documentation, and evidence. You also need it early enough that engineering, security, legal, and product can all work from the same assumptions.

Why Key Management Is Now a Boardroom Topic Under CRA

The pressure usually starts with a simple question from leadership: “Are we on track for CRA?” What sounds like a documentation exercise quickly turns into a design review of signing workflows, update pipelines, boot trust anchors, and operational ownership of private keys.

The reason is straightforward. The CRA doesn’t just ask whether your product includes security features. It asks whether you can maintain security across the product lifecycle, including vulnerability handling and trusted updates. If the keys behind those controls are weak, exposed, badly governed, or poorly documented, the whole control set becomes questionable.

The timeline forces earlier decisions

The CRA uses a phased timetable. Most provisions apply in full 36 months after publication, while incident and vulnerability reporting obligations activate within 21 months, which forces organisations to stand up secure signing workflows and cryptographic infrastructure sooner than many planned (sternumiot.com on CRA enforcement timing).

That matters at board level because key management has long lead times. Teams need time to:

• Select an architecture: HSM, KMS, secure element, TPM, or a mix.
• Change release workflows: Move signing out of ad hoc scripts and developer machines.
• Define ownership: Security, platform engineering, manufacturing, and compliance all touch the process.
• Create evidence: Logs, policies, diagrams, approvals, and technical-file artefacts don’t appear automatically.

A board doesn’t need to know every cryptographic primitive. It does need to understand whether the company can still place products on the EU market without reworking its release and trust model at the last minute.

Poor key management is now a business risk

The old mindset was that key handling lived with PKI engineers and embedded specialists. That isn’t enough anymore. If a signing key is extractable, if a device identity isn’t bound to hardware, or if revocation is improvised after shipment, the risk isn’t confined to a security finding. It can affect product shipment, incident response, and conformity claims.

Practical rule: If a private key can be copied by a person or process that doesn’t need to copy it, your design is already on the wrong track.

A practical example helps. Consider a connected industrial gateway. The product team may already encrypt storage and sign firmware. On paper, that sounds mature. But if the firmware signing key sits in a shared build server keystore, and if field devices trust updates without a documented key-rotation path, the organisation has a weak control plane behind a strong-looking feature set.

That is why CRA cryptographic key management requirements land in governance meetings. The board isn’t being asked to approve cipher suites. It’s being asked to fund the controls that make trusted products defensible.

Understanding the CRA’s Legal Mandate for Cryptography

The legal requirement isn’t “use cryptography” in the abstract. The CRA ties cryptographic practice to product security outcomes such as confidentiality, integrity, and protection against misuse. Once you read the Annex I obligations through that lens, key management becomes unavoidable.

Confidentiality requires more than encryption

CRA Annex I Part I.2(e) requires protection of data confidentiality for stored and transmitted data and explicitly requires secure key management alongside encryption. In IoT devices, poor key handling is a recognised failure point, and 22% of recent IoT vulnerabilities in the ES region stemmed from key mismanagement (cyberresilienceact.eu on disk encryption challenges).

That legal framing matters because many teams still describe compliance in terms of “we encrypt data at rest” or “we use TLS”. Those statements are incomplete. Encryption only protects data if the keys are generated properly, stored securely, released under the right conditions, and retired when necessary.

A practical example is automated disk decryption on a headless device. The device needs access to a decryption key during boot or startup. If the team hardcodes that key in firmware, stores it in a readable file, or injects it through a weak provisioning script, the encryption control looks good in a product brochure but fails under scrutiny.

Integrity and authenticity depend on trust anchors

The same legal logic applies to firmware and software authenticity. A product can’t claim trusted update delivery if the signing process relies on exposed private keys or undocumented trust anchors.

In practice, this means:

• Boot trust must start somewhere defensible: usually hardware-bound identity or a secure element.
• Signing authority must be controlled: not spread across unmanaged CI jobs or personal tokens.
• Verification rules must be explicit: devices need a clear policy for what they trust, when they reject, and how they recover.

If legal, engineering, and product teams need a common starting point for interpreting these obligations, the European Commission CRA implementation guidance overview is a useful bridge between regulatory language and product decisions.

What the mandate means in day-to-day engineering

The law doesn’t reward cosmetic cryptography. It rewards controls that hold up operationally.

Here is the distinction I use with clients:

If your architecture assumes that “trusted software” and “trusted key storage” are separate conversations, you’ll spend more time fixing evidence gaps later.

The legal test is evidence, not intent

A lot of teams have good intentions here. They mean to add revocation. They mean to separate development and production signing. They mean to formalise manufacturing keys after the next release cycle. The CRA pushes those plans into the present tense.

For manufacturers, the practical legal question is simple: can you show that confidentiality, integrity, and access control requirements are supported by real key management controls, not just by cryptographic libraries? If the answer is uncertain, you’re not looking at a small gap. You’re looking at a foundational compliance issue.

Managing the Full Key Lifecycle for CRA Compliance

Most CRA cryptographic key management requirements aren’t solved by buying one product. They’re solved by controlling the full lifecycle of each key type in your environment.

That means code-signing keys, firmware update keys, device identity keys, transport keys, disk-encryption keys, manufacturing keys, recovery keys, and any intermediate certificates that support trust decisions. Each one needs a purpose, an owner, a boundary, and an end state.

Start with a key inventory that engineers can use

Don’t begin with policy language. Begin with a working list.

For each key or certificate set, capture:

• What it does: firmware signing, secure boot verification, device authentication, storage encryption, backend TLS, manufacturing enrolment.
• Who owns it: platform security, product engineering, manufacturing, cloud operations, or supplier.
• Where it exists: HSM, cloud KMS, secure element, TPM, build service, device flash, recovery environment.
• When it’s used: build time, boot time, onboarding, update, runtime session, RMA, decommissioning.
• What breaks if it’s compromised: update trust, fleet identity, confidentiality, service access, or recovery operations.

Without this inventory, teams miss hidden keys. I often see organisations document firmware signing but forget factory provisioning keys or support-only recovery credentials. Those forgotten assets become the awkward part of the technical review.

Generation and issuance

Key generation should match the sensitivity of the key and the blast radius of compromise.

For high-value private keys, especially signing keys, generation needs tight control. You want a governed process with named approvers, recorded parameters, and a clear custody model. Generating a release-signing key on a laptop, even “temporarily”, is exactly the kind of shortcut that creates lasting evidence problems.

A good practical pattern looks like this:

1. Security defines the key class and approved generation location.
2. The key is generated in controlled hardware or through a managed service backed by controlled hardware.
3. Metadata is recorded immediately, including purpose, owner, validity window, and linked product line.
4. Access rights are assigned to roles, not individuals.
5. The public trust material is distributed to the systems or devices that need to verify signatures.

A bad pattern is just as common:

• developer creates key pair locally
• key gets exported for CI convenience
• same key ends up used in test and production
• no one can later prove the original generation path

Storage and protection

Storage is where many programmes drift from “secure enough in practice” to “hard to defend in an audit”.

Here is the simple rule: private keys should live where applications and users can’t casually extract them. For top-tier signing keys, that means hardware-backed protection. For device-side secrets, that may mean TPMs, secure enclaves, or dedicated secure elements depending on product class and hardware constraints.

Practical example:

• Non-compliant pattern: a firmware signing private key stored in a build runner filesystem, protected by an environment variable.
• CRA-aligned pattern: the build pipeline sends a signing request to a controlled service that uses a non-extractable key in an HSM-backed environment, while the build runner never sees the raw private key.

For products with encrypted local storage, the same thinking applies. If the decryption key sits in plain software-accessible storage, the encryption story is weak. If the key is released only after a hardware-rooted trust check, you’re on firmer ground.

Distribution and provisioning

Key distribution isn’t just a backend problem. It often breaks in manufacturing and field onboarding.

When devices are provisioned, teams need to answer practical questions:

• How does the device receive its initial identity?
• Is that identity unique per device?
• Is the identity tied to hardware?
• Can the provisioning station request more privilege than it should?
• Can a contract manufacturer copy trust material outside the intended flow?

This is one reason hardware-bound identity matters. It reduces ambiguity about who or what a credential belongs to. It also makes later evidence easier because you can show that trust starts in the device, not in a spreadsheet.

If you’re redesigning development controls around these flows, a CRA-aware secure software development life cycle reference helps teams tie key handling to release governance rather than treating it as a separate security track.

Use and access control

Keys should only be usable for their defined purpose. That sounds obvious, but many environments still allow broad, inherited permissions.

I recommend checking these points:

• Separate duties: the person who approves a release shouldn’t also be able to alter signing policy alone.
• Constrain usage: a code-signing key shouldn’t also issue device certificates or decrypt support archives.
• Log cryptographic actions: sign, rotate, revoke, import, delete, and policy change events need a durable trail.
• Use short trust paths where possible: fewer intermediates usually means fewer silent failure modes.

The strongest key-management design is often the one that removes human choice from the dangerous moments.

A broader architecture principle is helpful in these situations. If your release and device-authentication model is moving toward strong identity, least privilege, and explicit verification, Zero Trust Architecture Design is a useful companion read. It maps well to signing approval, workload identity, and service-to-service trust boundaries.

Rotation, revocation, and retirement

Rotation plans often exist only on paper. Under the CRA, that isn’t enough because vulnerability handling and secure updates depend on being able to change trust material under pressure.

A realistic rotation plan answers:

• Which keys rotate routinely and which rotate only on trigger events?
• How do devices trust the next key before the current one is retired?
• Can old signatures still be validated where necessary?
• How is compromise declared, approved, and communicated internally?
• What happens to devices that miss an update window?

Revocation is even more revealing. Teams usually discover too late that they can revoke a certificate in the PKI but can’t get field devices to reject signatures tied to an old trust root without a risky bootloader change.

A practical example:

• Weak approach: publish a revocation notice internally and plan to replace the key in the next major release.
• Stronger approach: maintain an updateable trust store on the device, define emergency revocation procedures, and test rollback-safe transition paths before release.

Retirement matters too. Old keys shouldn’t linger because “some legacy job still needs them”. If they do, document the dependency, isolate the use case, and set a retirement plan with named owners.

CRA key lifecycle management controls

What works and what doesn’t

What works is boring, repeatable, and controlled. Named owners. Hardware-backed protection for high-value private keys. Separate trust domains. Tested transition paths. Logging that survives scrutiny.

What doesn’t work is convenience-first crypto. Shared secrets in deployment scripts. Signing from developer workstations. Reused identities across product lines. “Temporary” exceptions that become permanent.

If your team wants one practical standard, use this one: every key should have a reason to exist, a protected place to live, a documented way to be used, and a planned way to die.

Choosing the Right Tools for Secure Key Management

Tool selection gets messy because teams often compare products that solve different problems. An HSM, a cloud KMS, a device secure element, and an open-source crypto library don’t compete directly. They sit at different layers.

The right question isn’t “what tool is best?” It’s “what key class are we protecting, where is it used, and what evidence will we need later?”

HSMs for high-value signing authority

For private signing keys, the CRA sets a very high bar. The requirement level for these keys effectively requires HSM-backed protection with FIPS 140-2 Level 3 certification, making this a mandatory measure for products subject to the CRA and EU market access (Encryption Consulting on CRA compliance and HSM-backed signing keys).

That should drive one clear decision. If you’re still protecting production firmware-signing keys in software-accessible stores, stop treating that as a mature interim state.

An HSM is the right fit when:

• The key signs firmware or software releases
• Compromise would affect many devices or product lines
• You need strong auditability and custody controls
• Multiple teams touch the release process

Trade-offs are real. HSMs add operational cost, approval workflow design, and integration effort. But for high-value signing keys, those trade-offs are usually easier than defending a weaker architecture.

KMS and cloud services for operational scale

A KMS can be excellent for application-layer secrets, service encryption keys, and controlled backend use cases. It often gives teams better operational speed, API integration, policy controls, and central management than hand-built key stores.

For cloud-native environments, managed services can simplify adoption. But don’t blur categories. A cloud KMS may fit runtime service encryption while still not being your final answer for the most sensitive release-signing authority unless the design and underlying controls meet your risk and evidence needs.

A practical split I often recommend:

If your current stack leans heavily on cloud secret storage, it’s worth reviewing where secret management ends and proper key custody begins. This overview of AWS Secrets Manager in CRA-related contexts is useful for drawing that line.

Secure elements and device hardware roots

On the device side, secure elements, TPMs, and enclaves often do the work a central HSM can’t do. They anchor local trust.

Use them when the product needs to:

• hold a unique device identity
• verify boot stages from a hardware root
• protect local keys used for storage or mutual authentication
• resist easy extraction in the field

For a simple practical example, compare two IoT sensor designs.

In the first design, every device in a product family ships with the same credential burned in during assembly. Support is easier at first, but compromise of one unit can undermine trust across the fleet.

In the second, each device gets its own hardware-bound identity and trust material. Provisioning is more disciplined, but compromise stays local and audit evidence is much stronger.

Hardware-backed identity tends to feel expensive until you price the operational pain of shared trust.

What open-source libraries can and can’t do

Teams often over-credit libraries such as OpenSSL, wolfSSL, mbed TLS, or BoringSSL. These are important building blocks for implementing cryptographic functions and secure protocols. They are not, by themselves, a key-management system.

A library can help you verify signatures, establish TLS sessions, or use approved algorithms. It doesn’t solve secure custody, approval workflow, tamper resistance, role separation, or evidence collection. If your product security narrative relies on a library name alone, it will look thin.

A practical selection rule by product class

Use a simple decision lens.

For consumer connected products, prioritise secure update signing, device uniqueness, and field-safe key rotation.

For industrial and embedded systems, add stronger focus on manufacturing provisioning, secure boot chains, and separation between operational technology and enterprise release authority.

For software-only products, concentrate on release-signing controls, backend secret segregation, and evidence-rich CI/CD approvals.

For multi-product manufacturers, centralise policy where possible but don’t force one key architecture across every product. The right answer for a battery-powered sensor isn’t always the right answer for a cloud-managed gateway.

Documenting Key Management for Your Technical File

A strong control that isn’t documented properly becomes hard to defend. Under the CRA, your technical file isn’t just a repository of diagrams. It’s the record that shows your cryptographic controls are deliberate, implemented, and auditable.

For key management, the file needs to answer three questions clearly. What keys exist. How they’re protected. How you know the controls are working.

What auditors and assessors need to see

CRA Annex I Part I.2(d) requires protection against unauthorised access, which in practice means auditable credential storage and cryptographic key management. The same analysis highlights hardware-bound Initial Device Identities (IDevIDs) per IEEE 802.1AR and HSM-backed key protection with FIPS 140-2 Level 3 as important technical evidence points for the technical file (ODVA CIP Security paper).

That gives you a practical documentation standard. Don’t just say “keys are protected”. Show the mechanism, the boundary, the process, and the evidence trail.

A workable structure for the file

A clean technical file section on key management usually includes the following.

Key management policy

This should define scope, ownership, roles, approval paths, and control objectives. Keep it specific to the product environment.

A useful model is to align it with the structure of an effective information security policy so it reads like an enforceable internal control, not marketing copy.

Include:

• Key classes: signing, device identity, transport, storage, manufacturing, recovery.
• Protection levels: which keys require hardware-backed custody and why.
• Role separation: who can request, approve, operate, review, and revoke.
• Environment boundaries: test, staging, production, manufacturing.
• Exception handling: who approves deviations and how they’re time-limited.

Architecture evidence

Teams often stay too high-level at this point. A single generic platform diagram isn’t enough.

Include practical artefacts such as:

• Trust chain diagram: root of trust through bootloader, firmware, update validation, and runtime identity.
• Signing workflow diagram: source control to build to approval to signing to release publication.
• Provisioning diagram: manufacturing enrolment, device identity issuance, backend registration.
• Key boundary diagram: where private keys reside and which systems never receive raw key material.

Procedural records

This is the operating evidence. It proves the system runs as described.

Add records such as:

• Generation records: request, approval, purpose, owner, environment, date.
• Access reviews: periodic review of who can trigger signing or administer policy.
• Rotation logs: planned rotations and emergency replacements.
• Revocation runbooks: steps, responsibilities, communication channels, field enforcement method.
• Incident tie-ins: how suspected key compromise is escalated and assessed.

If you need a practical framework for assembling this material, this guide to CRA technical file structure is a useful reference point.

A concrete example of good documentation

Suppose you’re documenting the firmware-signing process for a connected controller.

A weak description would say: “Firmware is signed before release using secure keys managed by the security team.”

A better description would say something like this, without needing to be verbose:

Production firmware is signed only through the release-signing service. The private signing key is stored in an HSM-backed environment and is not exportable. Build systems submit signing requests after release approval. The service logs requestor identity, artefact hash, approval reference, signing result, and timestamp. Devices verify signatures during update installation against the approved trust chain documented in Architecture Diagram KM-04.

That paragraph does real work. It names the mechanism, the boundary, the trigger, and the evidence.

Evidence that teams often forget

Some of the most useful supporting artefacts are not cryptographic at all.

• Change-control records show when trust anchors or signing policies were updated.
• Training records show that engineers and release managers understand the process.
• Supplier control documents show how contract manufacturers or external build partners are constrained.
• Test evidence shows that invalid signatures, revoked trust material, and outdated keys are rejected.

Documentation should let a reviewer reconstruct your trust model without interviewing your most senior engineer.

What not to put in the file

Don’t dump secrets, raw private key material, or operational details that create unnecessary exposure. The file should prove control, not leak sensitive implementation data.

Also avoid vague claims like “industry best practice”, “state of the art”, or “secure by design” unless you tie them to concrete controls. Reviewers don’t assess slogans. They assess evidence.

Your Actionable Key Management Compliance Checklist

Organizations generally don’t need another theory deck. They need a starting list that assigns work to the right people and exposes the gaps early.

Use the checklist below as a live programme tracker, not a one-off workshop artefact.

Manufacturer checklist

• Inventory every key class: Include signing, device identity, storage, manufacturing, backend, and recovery keys.
• Map each key to a product function: If a key has no clear business or technical purpose, remove it.
• Identify high-value private keys: Treat production signing keys as a top-priority remediation area.
• Move sensitive keys out of general-purpose storage: Replace file-based or script-managed custody with controlled hardware-backed protection where required.
• Separate test and production trust: Don’t let convenience create cross-environment signing risk.
• Document rotation and revocation paths: Make sure fielded devices can transition trust safely.
• Capture evidence as you build controls: Policies, diagrams, approvals, logs, and test results should be gathered continuously.

Importer checklist

Importers don’t design the cryptographic architecture, but they do need confidence that the manufacturer’s conformity claims are credible.

• Verify that key-management controls are documented: Ask for technical-file evidence, not a slide deck summary.
• Check secure update claims: Confirm that the product has a defensible signing and verification model.
• Review vulnerability-handling dependencies: If secure updates depend on weak key custody, post-market obligations become harder to trust.
• Escalate ambiguity early: If the manufacturer can’t explain where critical signing keys live or how compromise is handled, treat that as a material issue.

Distributor checklist

Distributors often sit closest to the point where commercial urgency can override technical caution. Resist that pressure.

• Confirm conformity artefacts are present: Missing or vague documentation around trust and updates deserves follow-up.
• Watch for unsupported product changes: Rebranding, repackaging, or modified firmware can affect trust assumptions.
• Maintain traceability: If questions arise about a product’s update integrity later, distribution records matter.

Three immediate actions for this quarter

1. Run a key-management gap review against your current release, provisioning, and device trust model.
2. Prioritise signing-key custody and evidence collection before lower-risk key classes.
3. Assign named owners across security, engineering, manufacturing, and compliance so key management doesn’t fall into organisational gaps.

The organisations that handle CRA cryptographic key management requirements well don’t treat them as a crypto-only project. They treat them as product governance implemented through engineering discipline.

If you’re trying to turn CRA obligations into a usable plan, Regulus helps manufacturers and digital product teams assess applicability, map requirements, structure technical-file evidence, and build a practical roadmap for 2025 to 2027 without managing the whole programme in spreadsheets.

La entrada Achieve CRA Cryptographic Key Management Requirements se publicó primero en Regulus.

Under the CRA, that is not just a technical debt problem. It is a market access problem.

For teams shipping software, firmware, and connected hardware into Europe, CRA secure update architecture requirements turn updates into a regulated capability. The update path has to be secure, resilient, explainable, and documented. It has to work across the product lifecycle, not just during launch. It also has to stand up to scrutiny from product security, compliance, quality, and the people compiling the technical file.

Navigating the New Reality of Secure Updates Under the CRA

Most product teams already have some form of update mechanism. That is not the hard part. The hard part is realising that many existing mechanisms were built for convenience, support efficiency, or feature delivery, not for legal defensibility.

A common example is the “good enough” updater. It checks a server, downloads a package, verifies a checksum, and installs on reboot. That may have felt mature a year ago. Under the CRA, it can expose several weaknesses at once. Who signed the package? How is the signing key protected? What happens if power drops halfway through installation? Can the user postpone a functional update without losing core device capability? Can the manufacturer prove what happened on the device afterwards?

Those are architecture questions, not just implementation details.

The practical shift is this. Secure updates are no longer a support function sitting at the edge of the product. They are part of the product’s safety, security, and compliance posture. Teams that still treat updates as an afterthought usually end up patching around design flaws late in the programme, which is expensive and messy.

What changes for engineering and product teams

The CRA pushes update design into core engineering decisions:

• Platform choice matters: A device with no spare partition, weak boot validation, or limited persistent state can be much harder to make reliable.
• Build pipeline design matters: If signing happens informally or outside controlled release flow, evidence quality collapses.
• UX matters: A compliant update process is not just secure. It also has to communicate failures, notifications, and user choices clearly.
• Supplier governance matters: Third-party modules and embedded software have to fit into the same trust model.

A lot of teams need a roadmap before they need another tool. If you are working through prioritisation, this Cyber Resilience Act compliance roadmap is useful for translating legal deadlines into programme milestones.

Practical takeaway: If your current update system depends on manual intervention, undocumented exceptions, or tribal knowledge, assume it needs redesign work.

What works in practice

The strongest programmes do not start with legal text alone. They map the regulation into concrete controls such as signing, validation, rollback, event logging, and release governance. Then they test those controls against realistic failure modes: interrupted download, corrupt package, expired certificate, wrong hardware target, failed first boot, and supplier-delivered component updates.

That is the level where compliance becomes real.

Decoding CRA Mandatory Controls for Secure Updates

The legal text can feel abstract until you translate it into behaviour on a real device. Once you do that, the requirements become more concrete.

The EU Cyber Resilience Act entered into force on December 10, 2024, with main obligations applying from December 11, 2027, giving manufacturers a 36-month transition period. EY’s Practical Reference Architecture for CRA Compliance identifies secure update requirements including REQ_ER4 for a secure and dependable update process and REQ_VH2 for vulnerability handling, with authentication and integrity protection aligned to BSI guidance. ENISA’s standards mapping aligns these requirements with Annex I, and EY notes that failure to comply could affect up to 80% of connected devices placed on the ES market (EY Practical Reference Architecture for CRA Compliance).

That sounds broad. In engineering terms, it comes down to a small set of mandatory controls.

Authenticity, integrity, and availability

Think of the update path like a bank deposit system.

Authenticity answers one question. Did this deposit really come from the bank, or did someone imitate the sender?

Integrity answers the second. Was the package altered after it left the bank vault?

Availability answers the third. Can the deposit reach the account holder when needed, without the process collapsing under normal failure conditions?

For CRA purposes, a compliant update system has to handle all three. Teams often focus only on the middle one. They hash the file and call it secure. That is not enough. A hash can tell you a file changed. It does not tell you whether the sender was authorised. And neither control helps if your delivery and install path can strand devices in a broken state.

Controls that need to exist in the product

A practical baseline usually includes:

• Authenticated update origin: The device verifies that the update was issued by an authorised manufacturer process.
• Integrity validation before install: The device rejects tampered or incomplete packages.
• Dependable installation behaviour: The install path has to fail safely.
• Vulnerability response support: Teams need a repeatable way to ship patches when new weaknesses are discovered.
• User handling rules: The update flow has to support the right balance of automatic security patching, notifications, and user control for non-security functional updates.
• Failure communication: If installation fails, the system needs clear signalling for support, operations, and documentation.

What Zero Trust thinking changes

Many update systems still assume that internal build networks, artefact stores, or device fleets are trustworthy. That assumption creates blind spots. Teams working through update hardening often benefit from broader guidance on how to implement Zero Trust Security because the same principle applies here: every stage of the update chain should verify trust, not inherit it.

A practical example

Take a smart access control device installed in apartment buildings. If it accepts any package fetched from a configured endpoint and only checks a transport-layer connection, the trust boundary is too weak. If the same device verifies a signed manifest, checks the target hardware model, validates package integrity, stages the update, and only commits after a successful reboot and health check, the design is far closer to CRA expectations.

The difference is not cosmetic. It is the difference between “we can update devices” and “we can prove the update path is secure and reliable.”

Architectural Pillars of a CRA-Compliant Update System

A secure update architecture is easier to design when you separate it into pillars. In practice, most failures show up in one of three places: trust creation, delivery, or device-side enforcement.

Cryptography and key management

The signing system is the root of trust for the update chain. If it is weak, everything built on top of it is weak too.

A sound design uses a dedicated signing service, controlled approvals, and key protection that is separate from ordinary build infrastructure. The release pipeline produces a build, but a controlled signing process authorises it. The device trusts the signature because it already contains, or securely obtains, the verification material needed to validate the signer.

A practical example helps. A smart thermostat vendor signs production firmware only after release approval. The private signing key is not stored on a developer workstation or in a general-purpose CI runner. The device firmware contains the corresponding public key or trust anchor. When the thermostat receives a package, it validates the signature before it stages anything for boot.

That design supports two important outcomes. First, a compromised delivery server cannot by itself push arbitrary firmware. Second, release governance is easier to evidence.

Teams refining this part of the stack often need to align release controls with secure development practices. This overview of DevOps security best practices is useful when you are tightening CI/CD, artefact integrity, and approval points around signing.

Secure delivery mechanisms

Delivery is where many legacy systems show their age.

Manual methods such as field technician USB updates still exist in industrial and embedded estates. They can have a place in controlled edge cases, but they do not scale cleanly, and they create evidence gaps. The verified CRA reference architecture explicitly treats manual methods such as USB as costly and impractical at scale for ES market compliance.

What works better is an organised delivery tier:

The delivery service should not be the final trust decision-maker. Its job is to move packages reliably. The device still needs to verify what it receives.

On-device verification and state control

The device is the last gatekeeper. At this stage, many architectures either become resilient or become fragile.

A compliant design usually needs:

• Manifest checking: Confirm model, version, compatibility rules, and dependency conditions.
• Signature verification: Validate before install, not after.
• Secure boot integration: Ensure the newly installed image remains trusted at boot time.
• State tracking: Record what was attempted, what succeeded, and what failed.
• Rollback logic: Recover automatically when a new image cannot boot or fails early health checks.

For teams treating CRA work as part of a broader lifecycle effort, the link between update architecture and secure engineering process matters. This guide on CRA secure development lifecycle SDL is useful because update compliance usually fails when release engineering, product security, and field operations are designed in isolation.

Tip: Do not let the server decide install success. The device should report success only after verification, activation, and post-boot health checks.

Implementing Common Update Patterns and Avoiding Pitfalls

Two update patterns come up repeatedly in products that need a practical path to CRA alignment. Both can work. Both can fail badly when implemented lazily.

A/B partition updates

This is the cleaner pattern when device storage and bootloader capabilities support it.

The device keeps two system slots. One is active. The other is inactive. The update is written to the inactive slot, verified, and then selected for the next boot. If the new slot boots successfully and passes health checks, it becomes the new active system. If it fails, the device reverts.

A smart TV is an easy example. The television runs from partition A while it downloads and writes the new image to partition B. After reboot, it tries B. If boot-time integrity checks fail or the application stack does not reach a healthy state, the bootloader falls back to A.

Why this pattern is strong:

• Atomic behaviour: The current running system is not overwritten mid-install.
• Fast rollback: The previous image remains intact.
• Clear state model: You can track active, candidate, boot pending, confirmed, and reverted states.

Where teams go wrong is assuming that having two partitions automatically means safe updates. It does not. You still need resilient state transitions, secure boot alignment, and confirmation logic after reboot. Otherwise, the device can bounce between slots or commit a broken image.

Package-based updates

Package-based models update selected components instead of replacing a full system image.

This can work well in more modular devices such as industrial gateways, advanced networking appliances, or products with separable applications, runtimes, and OS components. A package manager or orchestrator handles component versions and dependencies.

The advantage is precision. If a vulnerability is isolated to one user-space service, you may not need to replace the whole firmware image. The downside is complexity. Dependency handling becomes harder. Partial success becomes a real issue. Rollback logic often needs to operate per component and at system level.

A connected point-of-sale terminal is a good example. The base OS, payment application, connectivity stack, and device management agent may all update independently. That flexibility is useful, but the trust model has to be tighter because multiple components can affect system safety and compliance.

Side-by-side comparison

Pitfalls that regularly break compliance

A lot of update programmes fail for ordinary reasons, not exotic attacks.

• Hardcoded server assumptions: Devices tied to a single unchangeable endpoint become brittle during certificate changes, service migration, or incident response.
• Weak crypto lifecycle practice: Good algorithms on paper do not help if keys are poorly stored, rotated informally, or impossible to revoke cleanly.
• Rollback that exists only in slides: Many teams claim effective support but have never tested it under failed boot, interrupted power, corrupt storage, or version incompatibility.
• No user-facing clarity: If the device can defer updates, users need understandable notifications and consequences, especially when distinguishing security updates from non-security functional ones.
• Missing hardware targeting checks: Installing the right package on the wrong board variant is a classic avoidable failure.
• Ignoring component suppliers: An update architecture is not compliant if upstream modules arrive as opaque blobs with no trustworthy provenance.

What works better in the field

The most reliable designs use a signed manifest that contains package identity, version, target model rules, and install conditions. The device validates the manifest first, then the payload, then stages installation. It records every decision point.

For documentation-heavy programmes, one practical option is Regulus, which provides requirement mapping and Annex II and Annex VII documentation structure for CRA work, including update-process evidence planning. It is useful when engineering teams need to connect implementation decisions to the technical file without maintaining that mapping manually.

Key check: If you cannot simulate a failed install in a test lab and show exactly how the device recovers, the rollback design is not mature enough.

Logging Evidence and Documenting for Annex II and VII

A secure update process without evidence is hard to defend. Auditors and internal reviewers will not infer control quality from architecture diagrams alone. They will ask what happened, when it happened, how the device decided, and what records prove that decision.

For update compliance, logging has to serve two jobs at once. It supports operations during incidents and it supports the technical documentation that underpins conformity work.

What to log

The useful event set is broader than “update succeeded” and “update failed”.

Capture events around the full lifecycle:

• Availability checks: When the device checked for updates and what was offered.
• User decision points: Whether the user accepted, postponed, or declined a non-security functional update where that control exists.
• Validation steps: Signature verification result, manifest check result, compatibility result.
• Installation actions: Download start, download complete, staging, install start, install complete.
• Boot outcome: First boot into new image, health check pass, health check fail.
• Recovery behaviour: Rollback trigger, rollback complete, return to previous version.
• Communication events: User notification displayed, failure message generated, support telemetry emitted.

A good log tells a story in sequence. A bad log produces isolated fragments that no one can reconstruct later.

How to make logs useful as evidence

Structure matters more than teams expect.

Each event should be tied to a device identifier, software version, event time, result, and reason code. If validation fails, record why. If rollback happens, record the trigger. If the device postpones installation because of power or state conditions, log that too. These entries become far more useful when they map directly to specific Annex I requirements and to the technical file.

This guide on CRA logging and monitoring requirements is a practical reference when teams need to define the event catalogue and evidence model rather than just “turn on logging”.

Mapping update events to CRA requirements and evidence

Annex II and Annex VII documentation habits that help

Teams usually struggle less with logging than with packaging the evidence into the technical file.

Three habits make a big difference:

1. Keep a control-to-evidence matrix. For each update requirement, note which artefacts prove it. That can include design docs, test cases, logs, release approvals, and user instructions.
2. Store representative event samples. You do not need to dump raw fleet telemetry into the technical file. You do need clear examples of normal update flow, failed validation, and rollback behaviour.
3. Version your documentation with the product. If the update process changes, the technical narrative and supporting evidence should change with it.

Practical rule: If support, engineering, and compliance each maintain different names for the same update state, your evidence set will become inconsistent.

Defining Roles and Responsibilities Across the Supply Chain

Many products do not come from one engineering team. They come from a chain of firmware providers, module vendors, cloud teams, contract manufacturers, importers, and distributors. The CRA does not remove that complexity. It forces you to govern it.

The cleanest way to think about this is to follow the update trust chain from upstream component to end device.

Final product manufacturer responsibility

The final manufacturer owns the overall architecture.

That includes selecting the trust model, defining how updates are signed, deciding how device-side verification works, integrating supplier components, and ensuring the final product can satisfy update and vulnerability handling obligations across its supported life. The final manufacturer also owns the technical file and the coherence of the evidence inside it.

In practice, this means the manufacturer cannot shrug and say, “the Wi-Fi module vendor handles their own updates”. If that module affects the security posture of the finished product, the update path still needs to fit the product’s overall compliance design.

Manufacturers working through this accountability model often need a clearer legal-operational translation. This overview of CRA manufacturer obligations is useful because it ties role-based obligations back to product decisions.

Component supplier responsibility

Suppliers have a narrower but still important role.

A component vendor should be able to provide trustworthy software or firmware updates for its module, along with enough technical information for the final manufacturer to assess provenance, integration requirements, and compatibility risks. If a supplier update arrives unsigned, undocumented, or outside a managed release process, the final manufacturer inherits that risk.

A connected coffee machine is a straightforward example. The machine includes a touchscreen module, a Wi-Fi chipset, and a payment add-on from different vendors. If the Wi-Fi supplier issues a firmware fix, the coffee machine manufacturer should not inject it into production blindly. The package needs validation, target compatibility assessment, and integration testing inside the final product context.

Importers and distributors

Importers and distributors do not typically redesign the update mechanism, but they still have due diligence obligations before placing products on the market.

From a practical standpoint, they should verify that the manufacturer has the expected conformity process, documentation, and update handling arrangements in place. If a product reaches market with a visibly immature or undocumented update model, commercial actors downstream are exposed as well.

What governance looks like in a real programme

The most effective supply-chain arrangements usually define:

• Who signs what: Final build, component package, manifest, and release notes.
• Who approves release: Engineering, security, quality, and product owner roles.
• Who handles vulnerability-triggered updates: Internal PSIRT, supplier, or both.
• Who maintains evidence: Technical file owner, system architect, or compliance function.
• Who decides field deployment rules: Operations, customer success, product, or safety team.

Without that governance, update architecture becomes a patchwork of assumptions. That is exactly where failures surface during audits and incident response.

Your Practical CRA Secure Update Compliance Checklist

A solid update design is easier to review when the checklist is operational rather than theoretical. The fastest way to expose gaps is to ask whether the product can do the thing, whether the organisation can prove it, and whether the evidence is ready for Annex II and Annex VII.

Design and architecture checks

Start with the product itself.

• Trust anchor defined: The device has a clear trust model for update verification.
• Signing architecture documented: Private signing operations are controlled and separated from ordinary build activity.
• Device validation path implemented: The product verifies manifest, package, and target compatibility before install.
• Secure boot aligned: Boot-time trust extends the update trust model after installation.
• Rollback strategy chosen: The product has a real recovery design, such as A/B or another tested fail-safe mechanism.
• User control logic defined: Non-security functional updates can be postponed where required without breaking device functionality.

Implementation and verification checks

Now look at behaviour under stress, not just happy-path demos.

• Interrupted update tested: The device can survive loss of power, lost connectivity, or partial download without ending in an unrecoverable state.
• Wrong-package rejection tested: Hardware variants, unsupported versions, and incompatible dependencies are blocked reliably.
• Signature failure tested: Invalid or tampered packages are rejected and logged.
• Rollback tested in practice: The mechanism has been exercised on real hardware, not only simulated.
• Health confirmation implemented: A newly installed image is not treated as successful until boot and post-boot checks confirm it.
• Failure communication verified: Users and operators receive understandable signals when an update fails or is postponed.

Process and documentation checks

A strong system still fails compliance if no one can evidence it.

• Release approvals recorded: Each software release has traceable approval and signing records.
• Event catalogue defined: Logging covers availability checks, validation, install actions, boot outcome, rollback, and user notices.
• Evidence mapping maintained: Each update control is linked to a design artefact, test artefact, and operational record.
• Supplier update process governed: Third-party components are integrated through a controlled trust and validation model.
• User documentation prepared: Instructions explain how updates happen and what choices the user has where applicable.
• Post-market workflow connected: Vulnerability discovery feeds update creation, deployment, and evidence capture.

Quick review questions for leadership teams

Senior teams usually do not need the implementation detail first. They need clear risk questions:

The checklist is useful because it forces technical, compliance, and product teams to answer the same questions in the same language. That is where many CRA programmes become manageable.

Regulus can help teams turn this checklist into an auditable compliance workflow. The platform maps CRA obligations by product and supply-chain role, structures evidence for Annex II and Annex VII, and helps manufacturers organise update-process requirements, documentation, and vulnerability-handling work without relying on scattered spreadsheets.

La entrada Mastering CRA Secure Update Architecture Requirements se publicó primero en Regulus.

Many teams already have something they call vulnerability disclosure. Usually it is an email alias, an internal Slack channel, and a rough understanding that engineering will investigate serious reports when time allows. That may have been acceptable as a security maturity milestone. It is not acceptable as a regulatory control.

A CRA coordinated vulnerability disclosure policy template is not just a piece of website copy. It is a public compliance artefact, an internal operating model, and a source of evidence. If the published policy says you acknowledge reports quickly, legal and auditors will expect a ticket trail. If it promises safe harbour, counsel will expect wording that aligns with practice. If it names covered products vaguely, market surveillance authorities may conclude the policy is decorative rather than enforced.

I have seen teams make the same mistake repeatedly. They start by polishing language before deciding who owns triage, who can approve researcher replies, how third-party component issues are escalated, and where evidence will be stored. That order fails. The document must reflect a process that can run on a busy Tuesday when a researcher sends an incomplete report and your firmware lead is on leave.

The good news is that this is fixable. A strong CVD policy is not complex because the writing is clever. It is strong because each clause maps cleanly to a legal obligation and to a real internal workflow.

Why Your Old Vulnerability Policy Is Not CRA-Ready

The usual starting point looks harmless enough.

A company has a security@ mailbox. The website footer mentions responsible disclosure. One engineer checks the inbox when they remember. Legal has never reviewed the text. Product names are missing, response times are undefined, and the company has no published position on good-faith testing.

That arrangement breaks down the moment someone asks a compliance question instead of a technical one.

What teams usually have

Most pre-CRA policies fail in familiar ways:

• Mailbox-only reporting: A single inbox exists, but there is no published process for intake, triage, remediation, or public disclosure.
• Vague promises: The policy says the company will “review reports promptly” without defining acknowledgment or assessment expectations.
• No scope statement: Researchers cannot tell which products, firmware versions, cloud services, or mobile apps are covered.
• No safe harbour: Good-faith researchers are asked to report issues, but are given no assurance that ordinary testing will not trigger legal escalation.
• No evidence trail: The organisation cannot show who received a report, when it was acknowledged, what decision was made, or how the fix was communicated.

A regulator reading that policy sees ambiguity. A researcher reading it sees risk. Neither outcome helps you.

What scrutiny looks like in practice

Take a common example. A connected device vendor publishes a short page saying, “Please report vulnerabilities to our security team.” A researcher submits a report affecting a mobile app, cloud API, and device firmware. The company replies a week later asking for logs. Engineering argues the API is out of scope because the policy only mentions devices. Legal objects to the researcher’s testing method because the policy never described allowed activity. Support asks what to tell customers. Nothing is written down consistently.

That is what an immature CVD process looks like under pressure.

A CRA-ready policy does not just tell outsiders how to contact you. It tells your own teams how to behave when a report arrives.

Why generic language fails

A generic policy fails because the CRA requirement is about establishing and enforcing a coordinated vulnerability disclosure policy, not merely publishing a contact address. That means the document has to stand up as an operational control.

A solid policy answers practical questions such as:

If your current text cannot answer those questions without side conversations, it is not ready.

Deconstructing CRA Vulnerability Disclosure Obligations

A report lands on Friday at 16:42. The researcher says they can prove active exploitation against a cloud-connected feature your device depends on. Security wants to validate first. Legal wants to control external communications. Product wants to know whether the issue is even in scope. Under the CRA, that uncertainty is the problem.

The regulation treats coordinated vulnerability disclosure as an operating requirement. It has to be public, usable, and tied to your internal reporting and remediation process. That is why a CRA policy cannot stop at contact details and polite language. It has to function as evidence.

For practical drafting, read the obligation in two layers. Annex I, Part II requires a coordinated vulnerability disclosure policy as part of the manufacturer’s security posture. Article 11 adds a time-sensitive reporting duty for actively exploited vulnerabilities. Put together, those provisions turn a website policy into a compliance control that must stand up to review.

Annex I, Part II sets the baseline

Annex I, Part II is where many first-time CRA projects shift from “publish something on the website” to “define a process we can prove we follow.” The requirement is not satisfied by an inbox alone. The policy has to show who can report, what products and services are covered, how reports are assessed, and how disclosure is coordinated.

That changes how the document should be written. Vague statements such as “we review all submissions” or “we respond promptly” create avoidable audit friction. A regulator, market surveillance authority, or internal reviewer will ask what “promptly” means, who owns intake, and how the company decides whether a report is valid.

A policy that holds up under scrutiny usually covers these points:

• Public availability: easy to locate from the company website, usually through a security page and supporting security.txt reference
• Reporting channels: one or more monitored methods, with clear ownership and a fallback if the primary route fails
• Scope: named product families, software, firmware, cloud components, and associated services
• Handling steps: intake, validation, severity assessment, remediation routing, and communication checkpoints
• Researcher expectations: what testing is allowed, what good-faith conduct looks like, and what the company will not treat as hostile activity
• Disclosure rules: who decides timing, what conditions justify delay, and how customer communication is coordinated

This is the point many teams miss. The policy is not just for researchers. It is also an internal instruction set.

Article 11 changes the escalation path

Legacy disclosure policies often assume the process ends with triage, a fix plan, and customer communication. The CRA adds a separate obligation. If a vulnerability is actively exploited, the manufacturer may need to notify through ENISA’s reporting mechanism within a short timeframe set by Article 11, as noted earlier in the CRA text.

That requirement has immediate drafting consequences. Your policy, or the procedure behind it, needs to answer four operational questions:

1. Who decides whether exploitation is active.
2. Who is authorised to approve regulatory notification.
3. What evidence is required before filing.
4. How security, legal, product, and communications work through that decision without delay.

If those answers live only in Slack messages or tribal knowledge, the policy is incomplete from a CRA perspective.

Teams that already document control ownership for adjacent assurance work can reuse that discipline here. The objective is different, but the mechanics are familiar: named owners, approval points, retained evidence, and repeatable workflows. That is one reason existing programmes around SOC 2 penetration testing requirements often provide a useful model for escalation design.

A CRA policy has to map to the full handling lifecycle

The strongest CVD policies are drafted with the rest of the vulnerability process in view. They connect intake to validation, remediation, release planning, customer notice, and recordkeeping. That is where the CRA-specific angle matters. A template becomes much more useful when each clause can be tied back to a legal requirement or annex item and then traced to an internal control owner.

For that broader process context, the related guide to CRA vulnerability handling workflows and evidence expectations is useful because it places disclosure inside the larger remediation and documentation chain.

The clauses that matter in practice

Below is the short version of what a CRA-aligned CVD policy usually needs. The legal requirement sits in the regulation. The core compliance question is whether each clause can be evidenced in practice.

One trade-off is worth stating plainly. Do not promise fixed remediation timelines you cannot meet across every product line. Promise acknowledgment, structured assessment, defined ownership, and coordinated communication. Those commitments are easier to defend, and they are far more likely to match how an incident unfolds.

If the policy cannot be annotated back to the CRA and then matched to a working internal procedure, it is still a website statement, not a compliance tool.

Your CRA-Aligned CVD Policy Template

A manufacturer ships connected devices into the EU, copies its old vulnerability disclosure page from a general security policy, and assumes the job is done. Then legal asks how that page maps to CRA obligations, engineering asks which products are in scope, and the compliance lead cannot show how a public promise links to an internal procedure. That is the gap this template is meant to close.

Use the template as a controlled document, not just website copy. Each clause should map to a CRA obligation, an internal owner, and a piece of evidence you can produce during review. That is what turns a policy template into a compliance tool.

Template text

Coordinated Vulnerability Disclosure Policy

1. Purpose
[Company Name] receives, assesses, and addresses security vulnerability reports relating to our products with digital elements and associated services. This policy explains how security researchers, customers, partners, and other third parties can report suspected vulnerabilities to us and how we handle validation, remediation, and coordinated disclosure.

Annotation: Keep the opening tied to products with digital elements if you place products on the EU market. It aligns the policy language with CRA terminology and avoids a generic corporate security statement that is too broad to defend.

2. Scope
This policy applies to the following products and services supplied, maintained, or supported by [Company Name]:

• [Product family or SKU group]
• [Firmware and software components]
• [Mobile applications]
• [Cloud services and service back-end components]
• [Associated update infrastructure, where applicable]

Reports relating to third-party services or products outside our control may be redirected to the relevant vendor where appropriate.

Annotation: Scope is where weak policies usually fail. Name the product families, companion apps, cloud services, and update channels that matter. If your product boundary is unclear in the policy, it will also be unclear in triage, advisories, and audit evidence.

3. Reporting a vulnerability
Please submit vulnerability reports through one of the following channels:

• Email: [security@example.com]
• Web form: [URL, if used]
• Encrypted communication option: [PGP key location or secure exchange method, if used]

Please include, where possible:

• A description of the issue
• The affected product, version, or environment
• Steps to reproduce
• Proof-of-concept material, screenshots, logs, or recordings where relevant
• Your contact details for follow-up

Annotation: The reporting route must be public, monitored, and usable. If you offer encrypted exchange, make sure someone can process it. If you do not, leave it out rather than publishing a contact path that fails in practice.

4. Acknowledgment and communication
We will acknowledge receipt of a vulnerability report within 3 to 5 business days. We may request additional information where needed to validate the report. We aim to keep the reporter informed of material status changes during triage, remediation, and disclosure planning.

Annotation: Acknowledgment windows are easier to sustain than fixed remediation promises. Publish a response window you can meet across product lines, holidays, and leave coverage. Internally, many teams target same-day review, but the public commitment should match actual operating capacity.

5. Assessment and triage
Upon receipt, [Company Name] will review the report to determine:

• Whether the issue is a genuine security vulnerability
• Which products, versions, and customers may be affected
• Whether the issue involves third-party or open-source components
• The likely security impact
• Whether urgent containment or escalation is required

Reports that cannot be reproduced immediately will remain under review where sufficient information suggests a credible security issue.

Annotation: This clause needs a real workflow behind it. Product security, engineering, support, and dependency owners all need a defined handoff. If your internal triage process is outsourced or shared, document that internally even if the public policy stays simple.

6. Remediation and coordinated disclosure
Where a report is validated, [Company Name] will coordinate remediation and plan disclosure in a way that reduces risk to users while supporting responsible public communication. We aim for coordinated disclosure within a reasonable timeframe, but the timeline may change based on exploitation risk, technical complexity, customer exposure, patch validation, field deployment constraints, or required coordination with third-party vendors.

Annotation: Avoid hard-coding a single disclosure deadline unless you know you can defend it for every product class. SaaS products, embedded devices, and safety-relevant systems rarely move at the same speed. What regulators and researchers can evaluate is whether you have a defined owner, a decision process, and a documented reason when timing changes.

7. Active exploitation and regulatory reporting
If [Company Name] determines that a vulnerability affecting an in-scope product is being actively exploited, we will follow our regulatory incident and vulnerability reporting procedures, including required notifications to competent authorities and relevant platforms where applicable.

Annotation: Keep the public wording short. The internal procedure should define who decides that exploitation is credible, what evidence is required, who approves notification, and how that decision is recorded.

8. Public advisories
When appropriate, [Company Name] will publish vulnerability information after remediation or mitigation measures are available. Advisories may include affected products, impacted versions, severity context, mitigation guidance, and update instructions.

Annotation: Your advisory practice should match the products you sell. If you issue bulletins, release notes, or machine-readable advisories, align the policy with that format so the public statement and the delivery mechanism do not drift apart.

9. Safe harbour for good-faith research
[Company Name] welcomes good-faith security research conducted to identify and report vulnerabilities responsibly. We will not pursue legal action against researchers for activities that comply with this policy, avoid harm to users or services, respect privacy, and do not involve extortion, unauthorised data retention, or service disruption. We ask researchers to provide us with a reasonable opportunity to investigate and address reported issues before public disclosure.

Annotation: This clause affects whether credible researchers will engage with you. Legal teams often try to soften it into something discretionary. That usually backfires. If you invite reports, give a clear operating boundary and a clear statement of your position.

10. Researcher expectations
We ask reporters to:

• Act in good faith
• Avoid privacy violations, data destruction, or service interruption
• Use only the minimum testing necessary to confirm the issue
• Not publicly disclose details before coordination is complete, unless otherwise agreed
• Not demand payment or threaten disclosure as a condition of cooperation

Annotation: This balances the safe harbour language. It gives you a basis for dealing with extortionate or reckless conduct without discouraging legitimate reporting.

11. Policy maintenance
[Company Name] may update this policy to reflect changes in product scope, legal obligations, or operational processes. The current version will remain publicly available on our website.

Annotation: Put a version date on the page and retain prior versions internally. If the policy changes because your scope changed, your evidence set should show why.

What to keep and what to edit

Keep these clauses structurally intact:

• reporting channels
• acknowledgment window
• coordinated disclosure language
• safe harbour
• active exploitation escalation

Edit these for your environment:

• scope
• product names
• communication routes
• disclosure extension conditions
• advisory publication method

The discipline here matters. If the public text is too generic, it stops being useful to researchers. If it is too specific in the wrong places, you create promises the business cannot meet.

What weakens the template

Three edits usually reduce the policy’s value.

1. Removing safe harbour because legal is uncomfortable. That discourages responsible reporting and makes the invitation to report look hollow.
2. Using broad scope language with no product detail. That creates room for internal disputes about whether the report belongs to product security, support, or no one.
3. Promising fixed remediation speed across all products. That is difficult to defend once you account for third-party dependencies, hardware release cycles, or customer-managed deployments.

A usable CVD policy is one your incident manager, legal reviewer, and product team can all follow without inventing the process as they go.

Customising The Template For Your Products and Team

Customisation is where the template becomes defensible. The policy should sound like your product estate, your support model, and your engineering constraints. If it reads like a generic trust-center page, it will not hold up well in a CRA review.

Start with product boundaries

If you sell a connected camera, the product usually includes more than the hardware. Firmware, a mobile app, a cloud relay service, an account portal, and the update service may all sit inside the practical vulnerability boundary. If you sell enterprise software, the boundary may include on-premise releases, hosted management consoles, bundled agents, and update infrastructure.

Weak scope language:

• “This policy applies to our products.”

Stronger scope language:

• “This policy applies to the Acorn Hub gateway, Acorn Hub firmware, the Acorn Mobile app for device administration, and cloud services required for remote management and security updates.”

The stronger version gives researchers clearer targets and gives your internal teams less room to argue about scope. If your documentation set is still inconsistent, fix that at the same time. Policy scope and technical documentation scope should match. This guide to structuring your CRA technical file is useful for that alignment.

Match public promises to internal capability

A small firmware team and a mature SaaS PSIRT should not publish the same operational assumptions.

Use a simple calibration exercise:

The point is not to lower the bar. It is to publish commitments you can evidence.

Write safe harbour clearly

Weak version:

• “We may choose not to take legal action for authorised testing.”

Why it fails: “may choose” keeps all discretion with the company, and “authorised testing” is too vague to reassure a good-faith reporter.

Better version:

• “We will not pursue legal action against researchers acting in good faith under this policy, provided they avoid privacy violations, service disruption, extortion, and data retention beyond what is necessary to document the issue.”

That language still protects the company. It also gives researchers a boundary they can understand and act on.

Tailor disclosure timing without becoming vague

Some products can support a simple default timetable. Others cannot.

For a cloud service, this may be enough:

• “We aim to coordinate disclosure within a reasonable timeframe unless mitigation or customer action requires a different schedule.”

For embedded or industrial products, stronger wording is often:

• “We may extend the disclosure period where patch validation, field deployment constraints, or multi-vendor coordination make earlier publication unsafe or misleading.”

The difference is practical. Extension language should explain why the schedule may change, not just preserve company freedom.

Two practical examples

IoT vendor example

A smart lock manufacturer should usually include:

• device firmware
• mobile app
• update service
• account service used for provisioning or remote administration

It should also state whether physical tampering, radio testing, and lab-based analysis are in scope for good-faith research. If you prohibit hardware analysis, say that directly. Do not invite testing and then dispute the method after a report arrives.

Enterprise software example

A B2B software vendor often needs a split scope statement:

• self-hosted product versions
• managed cloud edition
• supported plugins or agents
• excluded custom deployments or unsupported legacy versions

That avoids a common dispute. A customer reports a vulnerability in a heavily customised deployment and expects the public policy to cover work the vendor does not control.

Implementing and Evidencing Your CVD Policy

A policy only starts counting when it is visible, used, and evidenced. Publishing the text is the easy part. Proving that the process works is what takes discipline.

Publish it where outsiders will find it

The minimum practical setup is usually:

• Dedicated security page: A /security or equivalent page that hosts the policy, version date, reporting channels, and advisory links.
• Security.txt reference: A standard pointer that directs researchers to the policy and contact route.
• Support page alignment: Your customer support and trust pages should not contradict the policy language.

A buried PDF in a legal repository does not help. Researchers need fast discovery, and auditors will ask whether the policy is public.

Build the internal workflow behind the page

The shortest useful workflow has named owners for intake, triage, engineering assignment, legal review, external communications, and closure. In smaller companies, one person may hold several roles. That is fine if the role ownership is still explicit.

A practical operating chain looks like this:

1. Report arrives through the published channel.
2. Intake owner logs it in the vulnerability tracker.
3. Product security or designated engineering lead validates the issue.
4. Product owner confirms affected products and versions.
5. Engineering plans fix or mitigation.
6. Legal and communications review any external messaging.
7. Advisory is prepared when appropriate.
8. Evidence is stored in the technical file repository.

Where teams stumble is step two. If reports live in email and never enter a trackable system, your evidence trail starts broken.

For engineering teams that need a refresher on patch handling discipline, a practical primer on how to apply a patch file can be useful as baseline process training, especially where remediation still relies on manual workflows.

Evidence that stands up to review

Do not try to evidence this with screenshots alone. Screenshots help, but they are not enough.

Keep a structured record set such as:

This material should connect cleanly into your broader CRA evidence package. A useful reference point for organising that material is this overview of a CRA compliance evidence pack.

Avoid common implementation mistakes

Three problems show up repeatedly in first-time rollouts:

• The policy and the mailbox are live, but nobody owns weekends or holidays. If you cannot offer around-the-clock coverage, publish realistic expectations and create an escalation rule for urgent reports.
• The policy promises updates to reporters, but nobody tracks communication state. Use ticket fields for last response, next update due, and external contact owner.
• The advisory format is invented from scratch each time. Create a standard advisory template now. Include affected products, fixed versions, mitigations, and user actions.

The published policy is only the front door. Auditors will walk through it and look for the corridor behind it.

Guiding Disclosure Pitfalls and Advanced Scenarios

The biggest mistake teams make is assuming the hard part is writing the template. It is not. The hard part is making sensible decisions when the report is messy, incomplete, inherited from a third-party component, or tied to a researcher who is losing patience.

When the report is weak but probably real

Some reports arrive with little more than a crash screenshot and a short note. Teams often reject these too quickly.

A better approach is to classify them in three buckets:

• Actionable now: Enough detail to reproduce and route immediately.
• Credible but incomplete: Needs follow-up questions, but contains enough substance to keep open.
• Non-actionable: Too vague, unrelated to security, or clearly outside scope.

The middle bucket matters. Closing those reports too aggressively creates needless conflict and may push the reporter towards public disclosure. Ask focused questions. Request exact product version, environment, and reproduction steps. Keep the conversation professional.

When the issue is in open-source or third-party code

A common assumption is that inherited vulnerabilities belong only to the upstream maintainer. That is not a safe operating model for CRA-regulated products.

If your product ships the component, you still need to assess impact in your product context, track remediation, and decide how your own customers will be informed. Waiting passively for upstream action often leaves product, support, and legal teams unprepared.

Use a simple decision table:

This is also where your reporting obligations may become more complex. If the vulnerability handling path intersects with wider authority notifications, your escalation logic should align with your broader CRA reporting obligations under Article 14, even if the public CVD policy itself stays concise.

When the researcher is difficult

Not every reporter is collaborative. Some send hostile deadlines, demand payment, or threaten immediate publication.

Do not overreact. Separate the behaviour from the technical content.

Useful responses usually follow this pattern:

1. acknowledge the report professionally
2. confirm whether you need more information
3. state that you are assessing impact and coordination requirements
4. avoid argumentative language
5. document every exchange carefully

If the message crosses into extortion or deliberate disruption, route it through legal and leadership quickly. But do not use one difficult interaction as a reason to weaken your public safe harbour language for everyone else.

Multi-vendor coordination is where maturity shows

A vulnerability affecting a device, a cloud dependency, a mobile app, and an integration partner rarely fits a neat timetable. Such scenarios cause rigid policies to fail.

Good handling usually means:

• one internal coordinator
• one source of truth for status
• shared draft messaging
• explicit approval checkpoints
• clear criteria for whether disclosure waits for a patch, a mitigation, or only validated customer guidance

The goal is not silence. The goal is coordinated communication that helps users act safely.

Mature disclosure programmes are not defined by perfect reports. They are defined by calm, traceable decision-making when the report is imperfect.

From Policy to Practice A Continuous Journey

A CRA coordinated vulnerability disclosure policy template is a starting instrument, not a finished programme. The teams that get value from it treat the document as a control surface for real work. They define scope precisely, publish clear reporting routes, give researchers credible safe harbour, and support every promise with an internal workflow and evidence trail.

That work does more than reduce regulatory exposure. It also makes product security less chaotic. Engineering gets cleaner routing. Legal gets defined escalation points. Support gets usable customer messaging. Researchers get a process they can trust.

Keep the policy current. Review it when your product boundary changes, when you add a managed service, when ownership moves between teams, or when an actual disclosure exposes a gap in the wording. The best CVD policies improve after use.

If you need help turning scattered CRA tasks into a structured compliance plan, Regulus gives manufacturers a practical way to map requirements, organise technical documentation, and operationalise vulnerability handling without managing the whole programme in spreadsheets.

La entrada CRA Coordinated Vulnerability Disclosure Policy Template se publicó primero en Regulus.

The Cyber Resilience Act changes the standard from “we have a process” to “show me the evidence, in order, with timestamps, ownership, and proof that the fix reached the product”. For software vendors, firmware teams, and connected device manufacturers, that is not a legal wording issue. It is an operating model issue.

Organizations often do not fail here because they ignore security. They fail because the evidence is fragmented. A scanner finds a flaw. A developer discusses it in chat. Someone opens a ticket later. The patch ships, but the release record does not point back to the original finding. Months later, nobody can reconstruct who knew what, when they knew it, and what happened next.

That is the gap this guide addresses. It turns the legal duty into an implementation plan you can run with. The focus is practical: what fields must exist in each record, how to structure the chain of custody, how to configure common tools so evidence is generated automatically, and how to keep the trail defensible over time.

If you need the wider legal context first, the overview at Cyber Resilience Act basics is a useful starting point. The rest of this guide stays close to the ground. It assumes you need something your engineering, product security, and compliance teams can put into use now.

Introduction

A CRA audit trail stops being abstract the moment someone asks a simple question about a real vulnerability: when was it discovered, who triaged it, what product versions were affected, what decision was taken, and where is the proof that the update was released?

That question exposes whether your records are administrative only, or auditable.

Most organisations already have pieces of the answer. GitLab has merge history. Jira has issue states. ServiceNow has incident records. SCA tools hold dependency findings. Release tooling knows what shipped. The problem is that these systems rarely create one coherent chain. The CRA vulnerability handling records audit trail has to connect discovery, assessment, remediation, disclosure, and post-release follow-up without gaps.

What changes under CRA in practice

Under the CRA, vulnerability handling evidence has to support post-market scrutiny, not just internal process reviews. That means records must be traceable, complete, and available in a form that can be inspected years later.

Three practical shifts matter:

• Evidence must be chronological. If your timestamps conflict across systems, the record becomes weaker.
• Evidence must be attributable. “Security team reviewed” is not enough. A named role, owner, or approver has to appear.
• Evidence must be operational. A written policy without linked tickets, scans, approvals, and release artefacts is weak evidence.

What teams usually underestimate

The hardest part is not collecting more logs. It is deciding what counts as the system of record.

A scanner output on its own is not enough. A patch note on its own is not enough. A Slack thread is not enough. The auditable unit is the vulnerability record plus the linked evidence around it.

The decisive shift is simple. Having a vulnerability policy is not the same as proving that the policy was followed for a specific issue.

That is why mature teams treat the audit trail as a product security data model, not as a folder full of PDFs.

Unpacking the CRA Mandate for Audit Trails

A market surveillance request rarely arrives at a convenient time. It usually lands after a release, during an incident, or when the engineer who handled the original issue has already moved on. At that point, the legal text stops being abstract. Your team either has records that show what happened, when it happened, and who approved each step, or it does not.

According to Encryption Consulting’s CRA compliance guide, the Cyber Resilience Act mandates manufacturers maintain thorough audit trails for vulnerability handling, with reporting obligations set to commence on 11 September 2026, including an initial early warning within 24 hours of awareness of an actively exploited vulnerability and a detailed notification within 72 hours. Records may need to be retained for up to 10 years, and non-compliance can risk fines up to €15 million or 2% of global annual turnover.

Those deadlines matter, but the operational requirement is simpler than the legal wording makes it sound. The CRA expects a manufacturer to prove that its vulnerability handling process worked for a specific issue, using records that stand on their own.

What auditors will test

Auditors do not start with your policy. They start with a vulnerability and ask your team to reconstruct the handling history from evidence. If that reconstruction depends on tribal knowledge, private chat messages, or someone remembering why a decision was made six months ago, the record is weak.

Three checks come up repeatedly:

I use a simple test with security teams. Hand the record to someone who was not involved and see whether they can explain the full sequence of events without asking follow-up questions. If they cannot, the audit trail is incomplete.

The record has to tell a complete operational story

For each vulnerability, the file does not need to be elegant. It does need to be complete.

A defensible record answers six practical questions:

1. How did the organisation become aware of the issue?
   Scanner finding, bug bounty report, internal test, customer escalation, supplier notice, or runtime alert.

2. What product scope was affected?
   Product name, version, component, deployment context, and any linked SBOM or asset reference.

3. How was the issue assessed?
   Severity, exploitability, exposure, business impact, triage notes, and the basis for the decision.

4. Who owned the response?
   Assigned engineer, security reviewer, approving role, and escalation path.

5. What action was taken?
   Patch, mitigation, configuration change, temporary control, accepted risk, or decision not to remediate, with justification.

6. How was closure verified?
   Retest result, commit or pull request reference, release ticket, advisory, and notification evidence where required.

Many teams encounter difficulty at this stage. They can show that work happened, but not that the handling process was followed in a way an external reviewer can verify.

Why post-market scrutiny raises the bar

Under the CRA, these records are not only for internal governance. They support post-market review, incident handling, and potential reporting duties long after the original fix shipped. That changes how teams should design the trail.

A Jira ticket with a severity field is not enough. A scanner result with a timestamp is not enough. A release note saying “security fixes included” is not enough. The CRA standard is the joined-up record across those systems, preserved in a form that still makes sense years later.

That is why retention, immutable logging, identity-linked approvals, and exportable evidence matter so much in practice. The issue is not whether your team acted responsibly. The issue is whether you can prove each decision from the record alone.

For teams aligning the audit trail with the notification workflow, CRA reporting obligations under Article 14 helps frame which timestamps and decision points need to appear in the underlying record.

Building Your Vulnerability Record The Definitive Data Fields

A strong record architecture is not a theory exercise. It is a schema. If the fields are wrong, your audit trail will be patchy no matter how disciplined the team is.

According to the Canada EFMS audit framework reference used in the verified data, a compliant architecture should capture three evidence artefacts: discovery logs with triage notes submitted within 24 hours of awareness, vulnerability management logs with CVE ID, CVSS score, and remediation tracking, and firmware update logs showing patch release. That structure creates an auditable chain of custody, and organisations implementing it can reduce audit response time by 40-60% through pre-indexed evidence correlation.

The core record fields

Below is the field set I recommend making mandatory in your primary vulnerability register.

• Record ID
  Internal unique identifier. Do not rely only on CVE because many findings begin before a CVE exists.

• Awareness timestamp
  The first moment your organisation became aware. This field is critical because other deadlines may run from it.

• Discovery source
  Example values: GitLab Dependency Scanning, Snyk, SonarQube, researcher email, bug bounty platform, customer support escalation, SIEM alert.

• Reporter reference
  Person, system account, or external reporter identifier.

• Product and version scope
  Product name, SKU or model family, software or firmware versions, branch, release train.

• Affected component
  Component name and version, ideally linked to the SBOM entry.

• Vulnerability description
  Short technical summary in plain language. Keep it concrete.

• External identifiers
  CVE ID if available, CVSS score and vector if used internally, advisory references.

• Triage status
  New, validating, accepted, duplicate, not affected, mitigated, fixed, disclosed, closed.

• Exploitability assessment
  Why it is or is not exploitable in your product context

• Severity and business context
  Product impact, user impact, safety implications if relevant, internet exposure, tenant scope.

• Owner
  Team and named person responsible for moving the issue forward.

• Decision log
  Every significant triage or risk decision, with timestamp and approver.

• Remediation plan
  Patch, config mitigation, compensating control, release path, target branch.

• Verification evidence
  Test result, rescan result, code review reference, QA sign-off.

• Release evidence
  Fixed version, release tag, deployment record, firmware bundle ID, customer advisory reference.

• Closure rationale
  Why the issue is considered resolved.

A practical example

A fictional record might look like this:

• Record ID: VULN-2026-0041
• Awareness timestamp: 2026-09-18T09:12Z
• Discovery source: SCA alert from GitLab pipeline
• Reporter reference: gitlab-ci security-bot
• Product and version scope: Edge Gateway firmware 4.8.x
• Affected component: openssl 3.x entry from SBOM package list
• Vulnerability description: Dependency flagged for remotely reachable flaw in TLS handling path
• External identifiers: CVE present, CVSS entered in vulnerability log
• Triage status: Accepted for remediation
• Exploitability assessment: Reachable on deployed internet-facing mode, not reachable on air-gapped mode
• Owner: Embedded Platform Team, named maintainer assigned
• Decision log: Security lead confirms remediation path and release branch at timestamped review meeting
• Remediation plan: Upgrade dependency, rebuild image, verify regression tests, release patched firmware
• Verification evidence: SCA rerun clean, integration test passed, approval linked from merge request
• Release evidence: Firmware package signed and published, deployment note linked
• Closure rationale: Patched release available and internal verification complete

This is not meant to be elegant. It is meant to survive inspection.

The three-tier evidence model in daily use

Think of the audit trail as three linked layers rather than one giant ticket.

Discovery layer

Awareness starts here. Good evidence includes:

• scanner output snapshot
• incoming researcher report
• internal triage note
• timestamped acknowledgement

If a vulnerability is first discussed in Microsoft Teams or Slack, that conversation is not your authoritative record. It can support the record, but someone must create the formal entry immediately.

Management layer

This layer carries the main lifecycle.

Use it to track:

• acceptance or rejection decision
• severity reasoning
• exploitability notes
• owner assignment
• remediation steps
• change approvals
• validation status

This is usually where Jira, Azure DevOps, or ServiceNow works best if the workflow is configured properly.

Update layer

Many teams fall short here. They can prove the issue was assessed, but not that the fix reached the shipped product.

Evidence here should include:

• build provenance
• package or firmware identifier
• release note reference
• deployment or publication timestamp
• post-release verification

If your ticket ends at “merged to main”, your audit trail is incomplete. The CRA vulnerability handling records audit trail needs proof of product-facing action, not just development activity.

For teams structuring broader documentation around these records, the CRA technical file structure guide is useful because it forces you to decide where each artefact lives and how it is referenced.

Operationalising Your Audit Trail with a Modern Toolchain

When starting, many teams should not buy a new platform. They should first make the existing stack produce better evidence.

The verified CRA logging guidance at Regulus logging and monitoring requirements identifies key audit trail elements such as complete security scan logs, remediation timelines with owner identification, change management logs, and evidence for public Coordinated Vulnerability Disclosure policies with triage timelines and severity ratings. It also stresses integration with real-time CVE scanning and dependency analysis workflows because of the strict exploited vulnerability notification deadlines.

What works in Jira, GitLab, and Azure DevOps

The best implementation is usually boring. It uses the tools your engineers already touch every day, but it removes optionality.

Jira workflow controls

A Jira issue type for product vulnerabilities should have mandatory fields and state transitions that enforce evidence capture.

Use:

• Required custom fields for awareness timestamp, product, affected version, component, owner, exploitability, and closure reason
• Transition validators so a ticket cannot move to “Fixed” without a linked merge request or change record
• Automation rules that stamp assignment time, approval time, and closure time
• Link types that separate “caused by”, “fixed by”, “validated by”, and “released in”

What does not work is using one generic bug template for everything.

GitLab or GitHub pipeline evidence

Your source platform is usually the cleanest place to collect technical proof.

Useful artefacts include:

• pipeline run IDs
• scanner results attached to commits or merge requests
• SBOM outputs from the build
• signed release tags
• deployment artefacts
• merge approvals and code owner history

When this data is linked back into the vulnerability record automatically, audit prep becomes far easier.

ServiceNow and GRC overlays

Some organisations need stronger governance controls, especially when engineering, security, legal, and operations all need visibility. In that case, ServiceNow Governance, Risk and Compliance is a useful reference point for thinking about how risk records, controls, exceptions, and audit evidence can sit above engineering workflows without replacing them.

Where dedicated compliance tooling fits

There is a limit to what you can do with stitched-together tickets and exports. If you have multiple product lines, multiple regions, and a formal CRA programme, a dedicated layer can help unify evidence.

One option is Regulus, which maps CRA requirements, supports vulnerability handling documentation, and helps organise Annex-oriented evidence alongside product records. That is useful when your pain point is not detection, but proving coverage across products and obligations.

This kind of tooling should complement your engineering stack, not become a parallel shadow process.

A practical integration pattern

The cleanest pattern usually looks like this:

If you are designing the monitoring side, open source SIEM options for CRA-aligned environments can help you think through how runtime event data should feed the same evidence chain.

A toolchain becomes audit-friendly when people do not need to remember extra compliance steps. The evidence appears because the workflow requires it.

What consistently fails

Three patterns fail repeatedly.

• Soft-required fields
  If a field can be skipped, someone will skip it during a busy incident.

• Chat-first decisions
  Security and engineering discuss a triage outcome in chat, but nobody writes the formal decision into the system of record.

• Manual evidence packs at quarter end
  By then, links have broken, artefacts have moved, and context is gone.

A modern toolchain should make the compliant path the shortest path.

Maintaining a Tamper-Proof Trail Retention and Access Controls

A record that can be edited without trace is weak evidence. A record that cannot be found after a product team reorganisation is also weak evidence. Long-term defensibility depends on integrity and access control, not just collection.

The CRA-focused guidance in the verified data stresses tamper-proof records such as timestamped logs, validation evidence, triage workflows, and remediation actions, with protections like cryptographic signatures, hash chains, or append-only storage. It also notes that no universal retention period applies to every log set, but recommendations can span from several months to a few years for some records, while broader CRA documentation may need to be retained up to the product support period or longer depending on the compliance context already discussed earlier.

Controls that make records defensible

Use a layered approach.

Append-only event storage

If your workflow platform allows history editing or silent field overwrite, preserve an event stream elsewhere. This can be a log store, WORM-capable archive, or signed audit ledger.

The key point is that every significant action creates a new event instead of replacing the old one.

Cryptographic integrity

Hashing and signing matter most for exported evidence packs, release artefacts, and key audit logs. If a team exports a record set for an assessment, you should be able to demonstrate that the contents were not altered afterwards.

Immutable timestamps

Time sync matters. If your scanner, ticketing system, and CI runner disagree on time, sequence becomes harder to defend. Standardise time sources and preserve the original system timestamp in each artefact.

Access controls that survive scrutiny

Role-Based Access Control should follow actual responsibility, not convenience.

A simple model often works well:

• Product security analysts can create, triage, and comment
• Engineering owners can update remediation fields and attach technical evidence
• Release managers can add release and deployment proof
• Compliance or audit staff can view and export, but not alter operational records
• Administrators can manage the platform, but their access should itself be logged and reviewed

Avoid shared accounts. Avoid broad edit access. Avoid giving senior stakeholders “just in case” write permission across all records.

A defensible audit trail logs not only the vulnerability lifecycle, but also who viewed, exported, or changed the record itself.

A practical retention checklist

Use this as a working baseline:

• Define the record classes
  Separate vulnerability tickets, scan logs, build artefacts, release artefacts, disclosure records, and exported evidence packs.

• Assign retention rules
  Match each class to legal, operational, and product lifecycle needs.

• Archive with context
  Store enough metadata to understand the record after tools change.

• Test retrieval
  Ask for a record from an older release and see whether your team can produce it.

• Review access periodically
  Leavers, contractors, and reorganised teams often leave behind permissions that weaken your control model.

Teams often focus on creating records and leave governance for later. That is backwards. If you cannot preserve and control the trail, the trail will not hold up when challenged.

From Records to Readiness Acing Your CRA Compliance Audit

A good CRA audit is rarely about producing more documents. It is about producing the right sequence of evidence quickly and without contradiction.

The verified evidence-pack guidance at CRA compliance evidence pack states that the CRA’s stage-gated reporting deadlines require discovery logs and triage notes within 24 hours, then detailed investigation records and remediation plans by 72 hours. It also states that organisations failing to implement this temporal sequencing experience 3-5x higher audit findings rates, and that automating the workflow in CI/CD can achieve over 95% compliance with reporting timelines, compared with 60-70% for manual processes.

What an auditor usually asks for

The best way to prepare is to rehearse with a specific vulnerability, not with abstract policy statements.

A realistic request set looks like this:

Show the complete record for one vulnerability from discovery to fix release.

Show when your organisation first became aware of it.

Show who triaged it and why the severity decision was made.

Show the affected products and components.

Show the remediation plan and the owner.

Show the evidence that the fix reached the released product.

Show any disclosure, notification, or internal escalation that followed.

If your team needs to assemble this by searching inboxes, the process is not ready.

A scenario with a legacy product

Consider a connected industrial gateway that has been on the market for years. The current engineering team inherited it. The original build server is gone. Dependency scanning was introduced late. A vulnerability appears in a third-party component still used by versions under support.

The audit-ready response is not to pretend the history is cleaner than it is. The response is to establish a present-day control set:

• current supported versions
• current known component inventory
• current vulnerability monitoring for that product line
• a formal register of known vulnerabilities and decisions
• evidence of updates or mitigations still being issued during support

If the vendor cannot prove historical perfection, it should prove current control and continuity.

Common pitfall one with off-system decisions

A triage call happens in Zoom. The product security lead says the issue is not exploitable. Everyone agrees. Nothing is written into the official record.

That creates a broken chain of custody. The fix is simple. Record the decision, reasoning, participants, and timestamp in the system of record the same day.

Common pitfall two with closure by merge request

Developers merge a patch and mark the issue resolved. No one links the release artefact, firmware package, or customer advisory.

Auditors do not care that the code merged if the product evidence stops there. Closure should require proof that the remediation left engineering and entered the release path.

Common pitfall three with optional metadata

A team lets engineers skip component references or product version fields when they are in a hurry.

This looks harmless until a later review tries to answer which shipped products were affected. Mandatory fields are unpopular at first and invaluable later.

The practical standard is consistency, not elegance. A plain, complete record beats a complex workflow with missing fields.

Common pitfall four with over-documenting noise

Teams sometimes react by storing everything. Every chat message, every duplicate scan, every low-value alert.

That creates retrieval problems and hides key decisions. Keep supporting evidence available, but make the authoritative record concise. Auditors need a defensible chain, not a digital landfill.

Conclusion

A workable CRA vulnerability handling records audit trail is built from disciplined basics. Clear record fields. Linked evidence across discovery, triage, remediation, and release. Tooling that captures timestamps and ownership automatically. Governance that keeps records intact and accessible long after the original team has moved on.

Teams that treat this as a paperwork problem usually end up with fragmented evidence. Teams that treat it as a product security operating model build something much more useful. They can answer hard questions quickly, respond better during incidents, and show regulators that their process is real.

The timing matters. Reporting obligations begin before many organisations feel ready, and legacy products complicate the picture further. Starting now gives you time to clean up data models, enforce workflows, and close the gaps that only show up when you try to reconstruct a real vulnerability from end to end.

The practical path is straightforward. Pick the system of record. Define mandatory fields. Link your scanners, ticketing, CI/CD, and release artefacts. Test retrieval. Then repeat until the process stops depending on memory.

If you need a structured way to turn CRA obligations into a working roadmap, Regulus helps teams organise applicability, requirement mapping, technical file evidence, and vulnerability handling records in one compliance workflow. It is a practical option for manufacturers and digital product teams that want to replace scattered spreadsheets with a more auditable process.

La entrada CRA Vulnerability Handling Records Audit Trail: A 2026 Guide se publicó primero en Regulus.

For product engineering teams, the retention rule matters because it turns documentation from a launch-time deliverable into a long-tail obligation. If an authority asks for evidence years after release, “we used to have that file” is not a compliance position. You need to be able to retrieve the shipped risk assessment, declaration, component inventory, update rationale, and vulnerability records tied to the version that went to market.

The hard part is not understanding that records must be kept. The hard part is building a system that still works when product lines change, suppliers switch, repositories move, and legacy SKUs continue receiving updates long after the original launch team has gone.

Your CRA Documentation in 2036 A Future Audit Scenario

It is 2036. An EU market surveillance authority asks for the technical documentation for a smart thermostat your company first placed on the market in 2026.

The request sounds simple. Send the technical file. In practice, the team now has to answer a chain of awkward questions.

Which firmware build was on the device when it first shipped? Where is the cybersecurity risk assessment for that version? Which third-party components were included? Can anyone still produce the SBOM that matched that release? Where are the records showing how vulnerabilities were triaged and how updates were issued during support?

One engineer points to an old shared drive. Another finds a spreadsheet with release notes, but the file naming convention changed twice. Legal has a declaration of conformity PDF, but nobody can prove it maps to the shipped software version. Security has partial records in a ticketing system that was replaced years ago. Procurement has emails about a component substitution, but not the final approval trail.

That is what retention failure looks like. Not one dramatic mistake. A slow loss of traceability.

The CRA changes the standard for what “keeping records” means. It is not enough to retain fragments. You need a retrievable evidence set that connects product version, security decisions, and conformity artefacts over the life of the product.

Practical takeaway: If your current answer to “where is the complete file for version 1.0?” is “it depends who you ask”, your retention model is already too weak.

Shared drives and spreadsheets fail for one reason. They store files, but they do not preserve context. An audit-ready system has to preserve both. It must show what was approved, when it was approved, which product version it applied to, and what changed later.

The Core Rule What Is the CRA Documentation Retention Period

The core rule is straightforward, though the operational consequences are not. Under Article 13(13), manufacturers must retain the technical documentation and the EU declaration of conformity for at least 10 years after the product is placed on the market, or for the entire support period if that is longer, and the support period itself has a minimum duration of 5 years unless the expected use time is shorter, as summarised by Cyberday’s CRA Article 13(13) requirement note.

Consider financial records for product cybersecurity

A useful way to explain this to engineering teams is to treat the technical file like regulated business records.

You do not keep financial documents only until the quarter closes. You keep them for the legally relevant period because someone may ask to inspect them later. CRA documentation works the same way, except the retention clock follows the product lifecycle rather than the accounting cycle.

That distinction matters. Teams hear “10 years” and stop there. The rule is not only “keep it for 10 years”. It is 10 years or longer if your support period runs longer.

What starts the clock

The reference point is when the product is placed on the market. For internal planning, teams should identify that date at SKU level and preserve it alongside the product record. If you cannot establish when a product entered the EU market, you will struggle to defend your retention timeline later.

This is one reason ad hoc document storage breaks down. The file may exist, but if the market-placement date is not linked to the right version and declaration, the retention schedule becomes guesswork.

A simple product example

Take a connected security camera.

Your product team promises support for 7 years. The instinctive conclusion is often “we keep the file for 7 years”. That is wrong. Because the baseline requirement is longer, you retain the file for 10 years, not 7.

Now take an industrial gateway with a support model that runs beyond a decade. In that case, the support period controls. The file stays available for the entire support period, because the legal retention obligation extends with it.

What works in practice

Teams succeed when they do three things early:

• Define support periods explicitly: Put the support end-date in the product record, not only in marketing copy or release notes.
• Tie retention to versions: Keep evidence by released version or release family, not just by product name.
• Lock the declaration to the file: The EU declaration of conformity should not live as a standalone PDF with no traceable link to the supporting evidence set.

Rule to remember: Treat every launch as the start of a long-lived evidence obligation, not the end of a project.

Key Documents You Must Retain for CRA Compliance

When teams imagine “technical documentation”, they imagine a single folder called compliance. That is not enough. The retained file needs to show how the product was designed, assessed, tested, supported, and updated from a cybersecurity perspective.

The practical way to handle this is to break the file into named artefacts with clear owners.

The core artefacts

The table below is a workable operating checklist.

What good looks like for each artefact

EU declaration of conformity

This should be controlled like a release artefact, not stored like a general legal template. It needs an unambiguous link to the product and version scope it covers. If your team is building or reviewing one, this guide to the CRA declaration of conformity is a useful reference point.

A common failure pattern is generating a declaration at launch and then never linking it back to the release package that justified it.

SBOM

For an SBOM, “good” means more than a manually written list in a spreadsheet. The useful version is generated from the build process, stored in a machine-readable format, and preserved with the release package.

A practical example: if your thermostat firmware includes open-source libraries, your retained SBOM should show the component names and versions that were present in the shipped build, not what happens to be in the repository today.

Cybersecurity risk assessment

Teams keep only the latest version in this area. That approach fails historical audits.

If your release from years ago accepted a specific risk because of a hardware limitation, you need to preserve that rationale as it existed then. Rewriting the assessment later may help current engineering, but it does not replace the contemporaneous record.

Vulnerability handling records

Do not retain only the policy. Keep the operating evidence.

For a practical example, if a customer report led to a firmware patch, your file should show the report intake, triage decision, remediation path, approval, and release linkage. Ticket references are helpful only if the underlying records remain available.

What gets lost first

The most fragile records are not the obvious ones.

• Release-specific approvals: Security sign-off captured in chat tools or informal email threads.
• Supplier change evidence: Notes on why a component swap was accepted.
• Historic test outputs: Reports overwritten by later test runs.
• Version mapping records: The bridge between product model, firmware build, and declaration scope.

Tip: If an artefact explains “why this version was considered acceptable at that time”, preserve it. Those judgement records become vital years later.

Retention Timelines Triggers and Durations by Role

Retention duties make more sense when you map them by role instead of treating the supply chain as one unit. Manufacturers, importers, and distributors do not all hold the same documentation set, and they should not build the same workflow.

The timeline also has a transitional shape. The CRA applies in phases; vulnerability and incident reporting begins earlier than the full obligations. This phased approach allows organisations time to align documentation practices, as described in timeline summaries.

Manufacturer obligations

Manufacturers carry the heaviest burden because they create the technical file and must be able to produce it to authorities.

For product teams, this means the retention process has to start at release readiness, not after shipment. The evidence set needs to be assembled while the engineers, security reviewers, and release managers still know what happened.

A practical example helps. A company shipping a connected access-control panel should preserve one release packet per market-relevant version. That packet should contain the approved risk assessment, release SBOM, test evidence, declaration reference, and vulnerability handling links. If a patch changes a dependency later, the updated evidence should be stored as a new retained state, not overwrite the original one.

Importer and distributor realities

Importers and distributors underestimate their own exposure because they are not writing the firmware or producing the technical file.

That is a mistake. Even where they do not create the full documentation set, they still need a disciplined way to obtain, verify, and retain the documents or copies relevant to their role. If the manufacturer’s filing is weak, the importer cannot solve that weakness at the last minute during an investigation.

In practice, importers should maintain a product intake checklist that confirms the declaration is available, the support period is clear, and the manufacturer can provide underlying documentation when requested. Distributors should not rely on verbal assurances that “the CE side is handled”.

The reporting timeline changes priorities

Many teams assume they can postpone operational work until the full applicability date. That does not hold up, because the earlier reporting date forces vulnerability handling to mature sooner. This overview of CRA reporting obligations under Article 14 is useful reading for teams building that process in parallel.

The consequence is practical. You may still be refining your long-term file structure, but your vulnerability intake, triage, and evidence capture flow needs to be functioning earlier.

A role-based handoff example

Consider one product travelling through the chain:

1. 
   

   Manufacturer releases a smart sensor
   The manufacturer creates the core evidence set, fixes the placed-on-market date, and stores the release-specific artefacts.

   
   
2. 
   

   Importer brings it into the EU
   The importer confirms the conformity paperwork is available and that the manufacturer can support requests tied to the product.

   
   
3. 
   

   Distributor supplies it onward
   The distributor verifies the product presentation and documentation state are not obviously deficient before supply.

   
   

Each party should record its own actions. The biggest failure mode here is assumption. The manufacturer assumes the importer will keep commercial records that explain traceability. The importer assumes the manufacturer will always be able to regenerate the specific declaration package. The distributor assumes any document gap is someone else’s problem.

What works and what does not

What works

• Role-specific checklists: Each actor records only what they must hold and verify.
• SKU-level traceability: Product identity, version, and market-placement data are linked.
• Stable escalation paths: Importers and distributors know who at the manufacturer owns compliance retrieval.

What does not

• One generic supply-chain folder: It obscures ownership.
• Informal assurances from upstream partners: Useful in meetings, useless in audits.
• Reconstructing records after a request arrives: By then the trail is already cold.

Key point: The CRA timeline is staggered, but your evidence discipline cannot be. Teams that wait for the final date discover they have reporting duties before they have retrieval discipline.

Building an Audit-Ready Retention Workflow

The best retention workflow is boring. It should not depend on heroic memory, manual chasing, or one compliance lead who knows where everything lives.

An audit-ready setup has four traits. It is centralised, version-controlled, release-linked, and hard to overwrite accidentally.

Step one Create a release evidence package

For every market-relevant release, create a package that can stand on its own years later.

That package should include the approved product description, the release-specific risk assessment, the SBOM, test outputs, the release decision trail, and the declaration linkage. Store these under a stable identifier such as product family plus version or firmware release tag.

A good rule is simple. If a future reviewer could not tell what shipped from the package alone, the package is incomplete.

Step two Automate collection wherever possible

Manual collection breaks first under release pressure.

The strongest teams generate evidence from delivery workflows. SBOMs come from the build pipeline. Test outputs are exported into the retained release record. Approval gates feed the evidence set instead of sitting only in chat or issue comments.

This is also where teams benefit from a structured CRA compliance evidence pack rather than assembling one from scratch every time.

Practical example for a firmware release

A connected lighting controller receives a firmware update.

• Build pipeline generates the release artefacts.
• SBOM is exported and stored against that build.
• Security testing output is attached.
• Product security reviews whether the existing risk assessment still holds or needs an updated decision record.
• Release management marks the package approved.
• The package is archived in the retention repository with immutable timestamps.

That process is repeatable. A manually assembled ZIP file on someone’s desktop is not.

Step three Preserve history, not just the latest state

Many engineering tools are designed for current-state efficiency. Compliance retention needs historical fidelity.

If your risk register updates in place, preserve snapshots at release points. If your ticketing system allows edits after closure, export the decision state into the release record. If suppliers change a component, retain the old and new assessment trail.

Many teams make a subtle mistake here. They think version control alone solves the problem. It helps, but a repository commit log does not explain the compliance significance of a change.

Step four Test retrieval before anyone asks

A retention workflow is only as good as its retrieval drill.

Pick a released product and ask your own team to produce the complete file from that version. Do not allow people to patch missing pieces from memory. If retrieval depends on asking around, your system is not ready.

A simple internal drill

Ask for these items for one historic release:

Why this matters financially

Poor record-keeping is not only a paperwork issue. Failure to retain and provide technical documentation can lead to penalties of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher, as stated in the CRA Article 13 summary at European Cyber Resilience Act Article 13.

That should change how teams prioritise retention work. Archiving evidence is not admin overhead. It is risk control.

Practical rule: Build your retention workflow so that a staff change, tool migration, or supplier exit does not erase the reasoning behind a shipped release.

Navigating the CRA Transition and Legacy Products

Many teams still assume the CRA is primarily a rule for products launched after the full application date. For organisations with existing portfolios, that assumption is simplistic.

Products placed on the EU market before the full applicability date are only subject to CRA requirements if, from that date, they are subject to a substantial modification, but public guidance does not yet define that threshold precisely, which creates ambiguity for long-lived products, according to the European Commission summary cited in the verified data at the CRA summary page.

Why legacy portfolios pose a significant challenge

If you maintain industrial controllers, smart building devices, embedded gateways, or long-supported firmware products, post-applicability date changes are likely. Security patches, dependency swaps, hardware substitutions, and feature updates all create questions.

The difficult part is not only legal interpretation. It is operational classification. Teams need a repeatable way to identify which planned changes may pull a legacy product into a new compliance posture.

A product roadmap review should therefore include a modification screen, not only a feature and release review.

A practical decision framework

Use a structured internal review for every legacy product update after the relevant date.

Ask these questions

• Scope: Does the change alter core product behaviour, architecture, or exposure?
• Security relevance: Does it materially affect the product’s cybersecurity posture?
• Component impact: Are you replacing or materially changing a significant software or hardware element?
• Support implications: Does the update change the declared support model or expected use assumptions?
• Documentation effect: Would a reasonable authority expect the technical file to be updated because of this change?

This does not produce a legal verdict on its own. It gives you a defensible internal process.

A legacy product example

Suppose you shipped an industrial PLC before the full applicability date and plan a firmware update in 2028.

If that update is a narrow security fix, your team should still document why it was treated as maintenance rather than a substantial modification. If it changes communications behaviour, introduces major new functionality, or significantly alters component structure, the analysis becomes more serious.

The point is to avoid two bad extremes. One is assuming every legacy patch is harmless. The other is treating every maintenance update as a full re-entry into CRA scope without analysis.

A dated roadmap and obligations tracker such as the one discussed in CRA deadlines 2025 to 2027 can help teams organise that transition work.

Best practice: For every SKU placed on the market before the full applicability date, create a legacy register with market-placement date, support end-date, planned updates, and a modification review note for each significant post-applicability date release.

What does not work

Do not leave the substantial-modification question to release week.

By that point, engineering wants to ship, legal wants certainty, and nobody has enough documented context. Legacy compliance decisions need to happen at roadmap stage, when there is still time to adjust scope, gather evidence, or change the release plan.

Your Path to Confident Long-Term Compliance

The CRA conformity documentation retention period is easy to summarise and hard to operationalise.

The durable approach is to treat retention as part of product delivery. Keep the technical file and declaration as a release-linked evidence set. Preserve historical versions, not just the latest state. Make vulnerability handling records retrievable. Review legacy portfolios before post-applicability date changes create surprises.

The teams that do this well are not always the ones with the biggest compliance function. They are the ones that assign ownership clearly and build retrieval into ordinary engineering work.

If your organisation can identify the version placed on the market, produce the matching documentation set, explain how vulnerabilities were handled, and show how support periods were determined, you are in a far stronger position than teams still relying on scattered folders and institutional memory.

Long-term compliance is not about perfect paperwork. It is about preserving evidence in a form that makes sense years later.

CRA Retention Period FAQ

Regulus helps manufacturers, IoT vendors, and digital product teams organise CRA applicability, classification, documentation, and evidence workflows in one place. If you need a clearer path from scattered release records to a defensible long-term compliance system, explore Regulus.

La entrada CRA conformity documentation retention period: 2026 se publicó primero en Regulus.

Why Your Product Logs Are Now A Critical Liability

For product manufacturers, the stakes have never been higher. The EU’s Cyber Resilience Act has elevated your product’s event logs from a background function to a critical compliance point, backed by severe penalties. Failure to comply could mean significant fines or, even worse, your product being pulled from the EU market entirely.

Think of your product’s logs as its “black box recorder.” If the data from an aeroplane’s black box could be modified after a crash, the investigation would be worthless. The exact same logic now applies to your products with digital elements. If a security breach occurs and your device logs can be tampered with or erased, they offer no reliable evidence. This leaves your organisation exposed and unable to prove you exercised due diligence.

From Technical Detail to Legal Mandate

Under the CRA, trustworthy logs are no longer just for your internal debugging team. They are a legal necessity, essential for both post-market surveillance and mandatory incident reporting. Regulators must be confident that when a vulnerability is exploited, the event records provide an accurate, unaltered account of what actually happened.

This change shifts the responsibility squarely onto manufacturers to design logging systems that are secure by design and by default. An insecure logging mechanism isn’t just a technical flaw; it’s a direct violation of the CRA’s essential requirements. For instance, if an attacker compromises a smart thermostat and can erase the entry logs, it becomes impossible to determine how the breach occurred or what other devices might be at risk. It’s precisely this lack of visibility the CRA is designed to eliminate.

The core principle is simple: if you cannot trust your logs, you cannot demonstrate compliance. Your ability to respond to security incidents and report them accurately to authorities—as mandated by the CRA—depends entirely on having a tamper-evident record of security-relevant events.

Turning a Burden Into an Advantage

This new focus on CRA log integrity tamper resistance creates an urgent engineering challenge. It forces product teams to prioritise the security of logging mechanisms from the very first stages of design. This is not just another box to tick; it’s a fundamental condition for market access.

However, a structured approach can turn this compliance burden into a genuine competitive advantage. By engineering robust, tamper-resistant logging systems, you not only meet your legal obligations but also strengthen your product’s overall security posture and build lasting trust with your customers. Platforms like Regulus are built to help teams navigate these new requirements, providing a clear framework that maps CRA obligations to specific engineering tasks so you’re prepared well ahead of the deadline.

Turning CRA Requirements Into Engineering Tasks

Moving from the legal language of the Cyber Resilience Act to the practical reality of your engineering backlog is the first real hurdle on the path to compliance. For your development teams, the formal text needs to be broken down into clear, actionable goals. Annex I is where you’ll find the core rules for CRA log integrity tamper resistance, and figuring out how to turn them into specific tasks is what separates compliant products from those that will struggle.

The Act isn’t just asking you to create logs; it’s demanding that you can prove they haven’t been touched. It requires manufacturers to build systems where security-relevant events are shielded from any unauthorised changes. This isn’t about just writing events to a file—it’s about building a fortress around that file.

Mapping Legal Rules to Technical Reality

At its heart, the CRA wants you to record security-relevant events so they can be used for monitoring and forensic analysis later on. This translates directly into concrete engineering work. Your teams will need to build a system that logs every significant action and, crucially, protects those logs from being altered or deleted, even by a user with high-level privileges.

“…provide security-related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions…” – Cyber Resilience Act, Annex I

This line from the Act is your starting point. It means your product has to keep a reliable record of who did what, and when they did it. For instance, if an administrator changes a critical security setting on a connected medical device, that event absolutely must be logged. But more than that, you have to be able to prove that log entry wasn’t tampered with after it was created.

Getting this right is fundamental to meeting many other CRA obligations, like post-market surveillance and incident reporting. Without trustworthy logs, you can’t accurately reconstruct a security breach, figure out how bad it was, or report it to the authorities within the required timeframes. The engineering choices you make here directly impact your ability to respond when things go wrong.

From Vague Rules to Specific Examples

Let’s make this more concrete. Imagine your product is a smart home security camera.

• Action: A remote user successfully logs in.
• Non-Compliant Logging: A simple log entry is created: [timestamp] - user 'admin' logged in. An attacker who gets in could easily delete this line or change the timestamp to cover their tracks.
• CRA-Compliant Logging: The log entry is cryptographically chained to the previous one (a technique called hash-chaining). It’s then stored in an append-only format, making it impossible to delete an entry without breaking the integrity of the entire chain.

In this compliant scenario, the engineering task isn’t just to “log the login.” It’s to implement a system where each log entry’s validity is tied to the one before it, creating an unbroken digital chain of evidence.

This idea of creating tamper-evident records is a core part of building a CRA secure development lifecycle, making sure security is baked in from the start, not bolted on as an afterthought. EU market data from 2026 shows just how critical this is. A striking 68% of investigated IoT devices from non-compliant manufacturers showed clear evidence of log tampering vulnerabilities. The fallout? Their incident response times were, on average, 72 hours longer than their compliant competitors.

This shows that the CRA’s focus on CRA log integrity tamper resistance is a direct response to real-world security failures. By translating these requirements into clear engineering tasks, you move from abstract legal rules to concrete, defensible product features that protect both your customers and your business.

Building Your Tamper-Resistant Logging System

Now that we’ve covered the legal framework, let’s get practical. Building a system that actually delivers CRA log integrity and tamper resistance isn’t about finding a single magic bullet. It’s about creating a layered, defensible logging architecture by combining several technical controls.

Think of it as building your product’s “black box”. This section is your engineering guide. We’ll walk through the essential technical controls and implementation patterns you need to design a system that stands up to scrutiny from both attackers and auditors.

Start with Immutable and Append-Only Storage

The absolute foundation of any tamper-resistant logging system is immutability. Once a log is written, it must be impossible to change or delete it without leaving a trace. The most common way to achieve this is with an append-only mechanism.

Imagine a doctor’s chart where new notes can only be added at the very end, with each entry dated and signed. You can’t just go back and erase a previous diagnosis without it being glaringly obvious. That’s exactly the principle you need for your security logs.

• Practical Example (Software-Enforced Append-Only): At the operating system level, you can set file permissions to make a log file append-only. On a Linux system, for instance, the chattr +a /var/log/secure.log command sets this attribute on the secure.log file, preventing even the root user from overwriting or deleting existing content.

• Practical Example (WORM Principles): This concept, originally from optical storage, is easily applied in software. Your logging service can be designed to programmatically reject any API call that tries to modify or delete existing log entries. For instance, a REST endpoint for your logging service might only expose a POST /logs method for adding new entries, with no PUT or DELETE methods available for existing records.

Weave a Web of Cryptographic Integrity

Append-only storage is a great start, but a determined attacker might try to alter log contents directly on the disk. This is where cryptography comes in, providing your next layer of defence. The goal here is to make any modification instantly detectable.

The best technique for this is hash-chaining. It works by creating a cryptographic link between each log entry, turning a simple list of events into a verifiable, secure chain.

A hash is a unique digital fingerprint of data. By including the previous log’s fingerprint in the current log’s data before hashing it, you create an unbreakable chain. If a single byte in any previous log is altered, its hash changes, breaking every subsequent link in the chain.

Practical Example of Hash-Chaining

Let’s look at some log entries for a smart lock:

1. Log #1: {"timestamp": "2027-10-26T10:00:00Z", "event": "Login failed", "user": "guest"}

   • Hash #1: abc123def (This is the hash of Log #1’s data)

2. Log #2: {"timestamp": "2027-10-26T10:01:15Z", "event": "Login successful", "user": "admin", "prev_hash": "abc123def"}

   • Hash #2: ghi456jkl (This is the hash of all of Log #2’s data, which includes Hash #1)

If an attacker tries to change “Login successful” in Log #2 to hide their tracks, the new hash of that log will no longer be ghi456jkl. The chain is broken, and the tampering is immediately obvious.

To add another layer of proof, you can periodically sign a batch of these hashes with a private key (a digital signature). This proves the logs originated from your device and not an imposter. For a deeper dive, explore our guide on CRA logging and monitoring requirements.

Comparing Technical Controls For CRA Log Integrity

Choosing the right mix of controls depends on your product’s architecture, risk profile, and development constraints. The table below compares the most common methods to help you decide.

No single control is a complete solution. A robust approach often combines a hardware root of trust to protect keys, hash-chaining to link logs, and append-only storage as a baseline defence.

Anchor Everything with Secure Time-Stamping

One of the oldest tricks in an attacker’s book is manipulating time. If they can alter the timestamps on logs, they can completely obscure the timeline of a breach, making forensic analysis a nightmare. This is why trusted, protected timestamps are so critical for CRA log integrity and tamper resistance.

Simply relying on the device’s local system clock is not enough—it can be easily changed. You need to use secure, verifiable time sources instead.

• Practical Example (Authenticated NTP): Don’t just use any NTP server. Use servers that support cryptographic authentication, which prevents man-in-the-middle attacks where an adversary tries to feed your device a false time. Your device’s ntp.conf file could be configured to require authentication keys from a specific trusted time server.
• Practical Example (Trusted Time-Stamping Authorities): For high-assurance scenarios, your device can send a hash of a log (or a batch of logs) to a third-party TSA. The TSA returns a cryptographically signed timestamp, giving you irrefutable proof of when that log existed. Your software would periodically bundle the latest log hashes, send them to a TSA’s API, and store the returned signed timestamp.

Leverage Hardware-Based Protection

For the highest level of assurance, you need to anchor your logging security in hardware. A hardware-based root of trust is far more resilient to software-based attacks.

• Practical Example (Trusted Platform Module): A TPM is a dedicated crypto-processor built for securing hardware. You can use it to securely store the private keys for signing logs and to “seal” log hashes to its internal state. This means the keys never leave the chip, making it practically impossible for software-based malware to steal them.
• Practical Example (Secure Elements): Commonly found in smartphones and payment terminals, a Secure Element is a tamper-resistant microcontroller. It’s capable of running a small, isolated logging agent and protecting its cryptographic keys from the main operating system. For example, a medical device could use an SE to generate, sign, and store critical event logs entirely within this secure chip, isolated from the less-trusted main processor.

Protect Logs in Transit

Finally, remember that logs are often at their most vulnerable when they’re on the move—being sent from the device to a central analysis server like a SIEM. An attacker who can eavesdrop on or modify that data during transmission can undermine all your other security efforts.

Always use strong, modern transport-layer encryption. TLS 1.3 is the current standard and should be considered mandatory for creating a secure tunnel for log transmission. This ensures both confidentiality (no one can read the logs) and integrity (no one can alter them) while they are in transit.

Using Secure Logs For Faster Vulnerability Response

The Cyber Resilience Act isn’t just about building secure products; it’s about how you act when things inevitably go wrong. This is exactly where CRA log integrity tamper resistance shifts from a design-time concern to your most valuable tool in a crisis. Without trustworthy, unalterable logs, trying to meet the CRA’s strict vulnerability disclosure timelines is practically impossible.

When a vulnerability hits, secure logs are what provide the hard evidence needed to piece together an attack, understand its scope, and report it with confidence. Your first questions will always be, “Are we affected?” and “How bad is it?” Only secure logs can give you a reliable answer.

A Tale of Two Thermostats: A Real-World Scenario

Let’s play this out. Imagine a zero-day vulnerability is found in a popular brand of connected thermostats, allowing an attacker to take them over remotely. Now, we’ll watch how two different manufacturers—one with CRA-compliant logging and one without—navigate the fallout.

Company A: The Unprepared

Company A’s logs are standard and editable. When news of the vulnerability breaks, their security team is in full-blown panic mode. The logs are a complete mess, filled with inconsistent timestamps and entries they simply can’t trust.

• The Problem: They have no way of knowing if the logs are genuine or if an attacker has already wiped their footprints by deleting or altering records. For example, they see login events but timestamps are out of order, making it impossible to build a timeline.
• The Result: They can’t confirm which devices were actually compromised. Did an attacker just poke around, or did they pivot into a customer’s entire home network? They have no idea.
• The Consequence: Their report to the authorities is late and hopelessly vague. They’re forced to issue a blanket warning to every single customer, causing massive brand damage and completely failing their CRA disclosure obligations.

Company B: The CRA-Ready

Company B, on the other hand, built a tamper-resistant logging system from day one. Their logs are cryptographically hash-chained, securely time-stamped, and stored in an append-only format.

• The Advantage: The moment the zero-day is announced, their team can query their centralised log data with complete confidence. Every entry is trustworthy. A quick script to verify the hash-chain across all device logs confirms no tampering has occurred.
• The Result: Within hours, they pinpoint the exact devices showing exploitation, see the specific commands the attacker ran, and map out a precise timeline of the breach. The cryptographic integrity of the logs gives them irrefutable proof.
• The Consequence: They deliver a detailed, accurate, and timely report to the authorities. They notify only the affected customers with specific, helpful remediation steps, preserving trust and demonstrating total control over the situation.

This little story brings home the immense operational value of CRA-compliant logging. It’s not about passing an audit; it’s about having the visibility needed to manage a security incident with skill and precision.

The controls that give you this power are straightforward. They form a foundation of trust for your entire incident response process.

This is how immutability, integrity controls, and secure time-stamping work together to create an audit trail you can actually rely on when the pressure is on.

The Quantifiable Impact of Tamper-Resistant Logs

The link between secure logging and effective vulnerability management isn’t just theoretical; it’s backed by hard data. In the EU, where the CRA sets the rules, this is especially true. For example, Spain’s National Cybersecurity Institute (INCIBE) reported over 15,000 cybersecurity incidents in connected devices in 2026, with a staggering 37% being harder to investigate because of untrustworthy logs.

A 2026 EY study analysing CRA reference architectures found that devices with built-in tamper-proof logging achieved a 78% faster vulnerability remediation time—averaging just 14 days compared to 62 days for products with legacy logging.

That speed isn’t just a “nice-to-have.” It’s absolutely critical for meeting the CRA’s tight disclosure windows, which can be as short as 24 hours for actively exploited vulnerabilities. You can read more about these findings in the EY report on CRA compliance.

Ultimately, investing in CRA log integrity tamper resistance is a direct investment in your organisation’s resilience. It gives you the tools not just to prove compliance, but to act decisively when it matters most. To dig deeper into these post-market obligations, check out our guide on CRA vulnerability handling.

How To Prove Log Integrity To Auditors

Achieving CRA log integrity tamper resistance is a serious engineering task, but all that effort means nothing if you can’t prove it to an auditor. When market surveillance authorities come knocking, they will expect concrete evidence in your product’s Technical File, not just vague promises.

You have to show them not only that your logs are secure but precisely how you secure them. This means creating a detailed, verifiable trail of your design decisions, technical configurations, and validation results. Simply stating you use “tamper-resistant logging” won’t cut it; you need to be ready to demonstrate it from the silicon up.

Assembling Your Evidence Package

Your Technical File must include a dedicated section that serves as an “evidence package” for your logging system. Think of it as building a case for your product’s trustworthiness, leaving no room for doubt. Auditors are looking for a clear story backed by tangible proof.

A great way to structure this evidence is by using established frameworks like the ALCOA data integrity principles. Ensuring your data is attributable, legible, contemporaneous, original, and accurate gives you a solid foundation for organising your documentation.

Here are the essential artefacts auditors will want to see:

• Architectural Diagrams: A clear diagram showing your logging mechanism is non-negotiable. It should map the entire journey of a log event—from its creation on the device, through any cryptographic chaining, to its final resting place in local or remote storage.
• Configuration Files: Provide anonymised but complete samples of your configuration files. This could be the setup for your logging daemon (rsyslog.conf), the rules for your append-only filesystem (fstab entries), or the configuration defining which security-relevant events get captured.
• Code Snippets Illustrating Logic: Include short, well-commented code snippets that show key security controls in action. A perfect example is the Python function that performs your hash-chaining, demonstrating how the hash of a previous log is baked into the current one.
• Key Management Procedures: Detail exactly how you manage the cryptographic keys used for signing logs. Explain how keys are generated, stored (e.g., in a TPM or Secure Element), rotated, and protected from unauthorised access. A practical example would be a documented procedure for provisioning keys during manufacturing.

Compiling these documents gives you a comprehensive and defensible record. For a deeper dive into structuring this, our guide on building a CRA compliance evidence pack offers more valuable insights.

Proving Resilience Through Testing

Documentation describes your intent, but testing proves the reality. Auditors give significant weight to independent security assessments that specifically target your logging system. Just running a generic vulnerability scan is not nearly enough.

Your evidence package must contain test reports that validate your claims of CRA log integrity tamper resistance.

A penetration test report that concludes, “Attempted to modify log entry #451 via root access and verified that the cryptographic chain was broken, triggering an integrity alert,” is infinitely more powerful than a simple statement of compliance.

Your testing evidence should include:

1. Penetration Test Reports: Commission tests where assessors actively try to break your logging controls. Their report must detail every attempt—successful or not—to delete logs, modify entries, or alter timestamps.
2. Integrity Verification Scripts: Provide the actual scripts or tools your QA team uses to periodically check the integrity of log chains. This shows you have an automated process for continuous monitoring, not just a one-time setup. For example, a simple Python script that iterates through a log file, recalculates hashes, and confirms the chain is intact is excellent proof.
3. Secure Boot Validation: Document how your system’s secure boot process protects the logging agent itself from being tampered with before it even starts. This proves the root of trust for your entire logging mechanism.

Platforms like Regulus are designed to help you organise this evidence, linking your architectural decisions directly to CRA requirements. This creates an audit-ready trail that makes reviews smoother and demonstrates thorough due diligence, ensuring you can confidently place your product on the EU market.

Your Roadmap To CRA-Compliant Logging

The Cyber Resilience Act isn’t just a set of abstract rules; it demands a clear, actionable plan to turn theory into a working reality. The clock is ticking, and building a practical roadmap for CRA log integrity and tamper resistance is a series of concrete steps that must begin today.

Think of this as your project plan for market readiness. The journey starts with a frank assessment of where your logging capabilities stand now and ends with a product that is not just compliant, but demonstrably secure and trustworthy. Procrastination isn’t an option. Starting now is your single biggest advantage.

Your Step-by-Step Action Plan

To consolidate the key takeaways from this guide, here is a five-step roadmap to steer your organisation towards full CRA compliance for your logging systems. Each step builds on the last, creating a structured path from discovery to documentation.

1. Audit Your Current Logging Capabilities: Start by taking an honest look at what you already have. Do you log security-relevant events at all? Are those logs stored in a way that prevents simple deletion or modification? This initial audit against CRA requirements will immediately reveal your biggest gaps and help you prioritise engineering efforts.

2. Architect With Tamper Resistance As A Core Principle: Secure logging cannot be an afterthought. You must embed tamper resistance into the core architecture of your product from day one. This means making deliberate choices at the design stage about using append-only mechanisms, cryptographic integrity, and secure time sources, rather than trying to retrofit them later when it’s far more costly and complex.

Implementation And Verification

Once your architecture is defined, the focus shifts to execution and proof. This is where your engineering teams build the necessary controls and your quality assurance teams validate that they actually work as intended. To ensure your logging system meets all necessary regulations, it’s essential to integrate a robust framework that addresses general compliance standards.

3. Choose And Implement The Right Technical Controls: Select the right mix of controls—like hash-chaining, digital signatures, and hardware-based key storage—that fit your product’s specific risk profile and technical constraints. Crucially, you must document why each control was chosen.

A common pitfall is over-engineering a solution with complex tools like blockchain when a simpler, well-implemented hash-chain would suffice. The goal is effective, justifiable security—not complexity for its own sake.

4. Integrate Log Integrity Verification Into QA: Your testing pipelines need to include specific tests designed to break your logging system. Create automated scripts that attempt to alter logs and verify that your cryptographic chains correctly detect the tampering. These test results become powerful, objective evidence for auditors.

5. Assemble The Necessary Documentation: Finally, gather all the evidence into a coherent package. This includes your architectural diagrams, key management procedures, relevant code snippets, and penetration test reports. This collection becomes a critical part of your Technical File, demonstrating your due diligence and readiness for regulatory scrutiny.
   

Navigating this journey alone is demanding and carries significant risk. A strategic partner like Regulus provides the framework and tools to streamline this process, helping you reduce risk and confidently place your products on the EU market.

Frequently Asked Questions

Getting to grips with CRA log integrity and tamper resistance can throw up a lot of practical questions for manufacturers and developers. Here are some of the most common ones we hear, with answers to help clarify the key concepts.

What Counts as a Security-Relevant Event Under the CRA?

The CRA doesn’t give you a prescriptive checklist, and for good reason. What’s “security-relevant” depends entirely on your product. The best guiding principle is to ask: “What information would our security team absolutely need to reconstruct and investigate a breach?”

Think about the breadcrumbs needed for a forensic investigation. At a minimum, this usually includes:

• Authentication: Every login attempt, both successful and failed.
• Configuration Changes: Any modification to critical settings like firewall rules, user permissions, or security policies.
• System Actions: Administrator commands, attempts to update firmware (both successful and failed), and system restarts.
• Security Anomalies: Things like detected intrusions, a sudden spike in failed access attempts, or other events that your product flags as potential threats.

Logging these events isn’t just a tick-box exercise; it’s fundamental for the monitoring and post-market surveillance the Act demands.

Are Cloud-Based Logging Solutions Acceptable for CRA Compliance?

Yes, absolutely. In fact, using a cloud-based logging service can be a smart way to achieve tamper resistance, as it gets sensitive log data off a device that might be compromised.

However, the responsibility is still yours to secure the entire log pipeline from end to end. This means you must be able to prove that:

• Log transmission from your device to the cloud is encrypted and authenticated, typically using a modern standard like TLS 1.3.
• The cloud storage itself is hardened with strong access controls and immutability features, such as append-only buckets.

When you put together your technical documentation, be ready to show exactly how you secure this cloud environment. You’ll need to detail how you protect logs from being altered—even by privileged cloud administrators—to demonstrate true, end-to-end integrity.

Does the CRA Require a Specific Technology like Blockchain?

No, and this is a crucial point. The Cyber Resilience Act is deliberately technology-neutral. It mandates the outcome—tamper resistance—but leaves the how up to you.

While blockchain is one way to create a tamper-evident record, it’s often far too complex and resource-hungry for many embedded products. Simpler, more practical methods are perfectly fine and, in most cases, a much better fit.

For example, a system using hash-chaining combined with periodic digital signatures and secure time-stamping can fully meet the CRA’s requirements. The key is to choose a method that makes sense for your product’s specific context and that you can clearly justify in your audit documentation.

Navigating these requirements can be complex, but you don’t have to do it alone. Regulus offers a comprehensive platform to help you map your obligations, generate audit-ready documentation, and build a clear roadmap to CRA compliance. Gain clarity and confidence by visiting https://goregulus.com.

La entrada CRA Log Integrity Tamper Resistance Explained se publicó primero en Regulus.

What the CRA Means for Open-Source Projects

The central question for many developers is whether the Cyber Resilience Act imposes new rules on every open-source project. The answer is a clear no, but the details matter. To bridge the gap between community-driven development and the commercial world, the legislation introduces a specific role: the “open-source steward”.

This distinction is fundamental. It separates individual contributors from organised legal entities that provide structured, ongoing support to open-source software that ends up in products sold on the EU market.

Think of it this way: a hobbyist maintaining a personal garden shed isn’t subject to commercial building codes. A professional contractor managing the construction of public infrastructure, however, certainly is.

Who Is a Steward?

The CRA defines a steward as a legal person—such as a non-profit foundation or a company—that ensures the viability of an open-source project intended for commercial use. The focus isn’t on the person who writes the code, but the organisation that governs it.

• Practical Example (Steward): The Apache Software Foundation, which provides governance, infrastructure, and coordinated vulnerability management for projects like the Apache HTTP Server, would likely be considered a steward for its projects used in commercial applications.
• Practical Example (Not a Steward): An independent developer who creates and maintains a popular JavaScript library on GitHub in their free time is not a steward, even if that library is used by thousands of companies.

This guide walks through what defines an open-source steward and their specific duties under the law. We’ll cover the key CRA open-source steward obligations, which centre on security policies and vulnerability handling, and explain the steps manufacturers must take to work with them.

The introduction of the “steward” role acknowledges the unique position of open source. It applies formal responsibilities only where there is an organised, systematic effort supporting commercial activities, protecting the vast majority of individual contributors from regulatory burdens.

With key obligations taking effect throughout 2026 and 2027, understanding these roles is vital. This article maps out the timeline so you can prepare effectively for the new requirements. You can also explore our guide to understand how the CRA impacts different open-source licensing models.

Identifying an Open Source Steward

Knowing who the Cyber Resilience Act considers an “open-source software steward” is your first and most important job. This isn’t about targeting individual volunteers or hobbyist coders. Instead, the CRA is very specific: a steward is a legal person—think a company or a foundation—that provides systematic, ongoing support to an open-source project meant for commercial use.

This distinction is everything.

Picture a single developer maintaining a small GitHub library in their free time. Even if that library gets popular, they are not a steward. Their work is personal, not tied to a formal legal entity with a commercial support structure behind it.

In sharp contrast, you have the major foundations that govern critical projects used in thousands of commercial products. Organisations like the Linux Foundation or the Apache Software Foundation are prime examples. They provide the infrastructure, governance, and coordinated vulnerability management that allow businesses to rely on their software. Their support is systematic and enables commercial activity, which is exactly what the CRA is looking at.

The Three Core Criteria of a Steward

To figure out if an organisation is a steward, you can check it against three core criteria from the CRA. An entity has to meet all three to have CRA open-source steward obligations. This framework neatly separates informal community work from the structured, commercial-facing support the regulation is designed to cover.

1. Legal Person Status: The entity must be a registered legal person. This could be a non-profit foundation, a trade association, or a for-profit company. An informal group of developers without a legal structure simply doesn’t qualify.
2. Systematic and Sustained Support: The support can’t be a one-off contribution or sporadic help. It has to be an organised, ongoing effort to keep the project viable. This includes managing releases, coordinating development, or providing core infrastructure.
3. Intended for Commercial Activities: The open-source software must be developed with the clear intention of being integrated into commercial products. This is the key link that connects a steward’s activities directly to the EU market.

This clear separation protects individual contributors while placing responsibility squarely on the organisations that formally enable open source to be used in the commercial world. Understanding this is also vital for manufacturers, who need to pinpoint which of their software dependencies are managed by a steward to streamline their own compliance. You can learn more about how these duties compare to the responsibilities of a product lifecycle manager under the CRA.

To make this even clearer, the checklist below breaks down what it takes to be considered a steward under the CRA.

Identifying an Open Source Steward Criteria Checklist

An organisation must meet all three of these criteria to be classified as a steward. This ensures the regulation focuses only on entities that have a formal, structured role in the commercial open-source ecosystem.

Practical Examples: Steward vs. Non-Steward

Let’s apply these criteria to a couple of real-world scenarios to make the distinction crystal clear.

Example of a Steward:

• Organisation: The Eclipse Foundation.
• Why it qualifies: It’s a legal non-profit entity that provides strict governance, intellectual property management, and a formal development process for huge projects like Jakarta EE. This systematic support is precisely designed to make these projects stable and reliable enough for businesses to build commercial products on top of them.

Example of NOT a Steward:

• Organisation: A group of five friends collaborating on a new open-source game engine.
• Why it doesn’t qualify: While they work together, they are not a registered legal entity. Their support, however valuable, lacks the formal, systematic structure and clear commercial intention required to be considered a steward under the CRA.

Open-source software stewards under the EU CRA are defined as legal persons—not individuals—systematically supporting specific OSS development for commercial use. Research shows that while many potential stewards demonstrate high readiness in security practices (74-79% adoption of key measures), a significant gap exists, as only 32% currently produce SBOMs, a core element for supply chain transparency. You can explore more about what the CRA means for open source on berthub.eu.

Implementing Secure by Design Policies

The Cyber Resilience Act is forcing a big change for open-source stewards. It’s taking security from a community handshake to a set of formalised, documented processes. The principle of “secure by design” is at the very core of these new CRA open-source steward obligations. This isn’t about starting from scratch; it’s about making your security practices predictable, reliable, and transparent.

Instead of relying on gut feelings or one-off decisions, stewards now need a documented cybersecurity policy. Think of it as the project’s security playbook, explaining how you handle security from the first line of code to the last patch. It’s all about consistency and accountability.

From Informal Norms to Formal Policies

For ages, security in open-source projects has been part of the culture, just not always written down. The CRA changes that by requiring this culture to be codified. You’re essentially translating those unwritten rules into documented procedures that anyone—from a first-time contributor to a downstream manufacturer—can follow.

A huge part of this is having a documented policy for finding and managing vulnerabilities. This policy becomes the foundation for how your project builds and maintains secure software. It’s less about checking a box for regulators and more about building a system that people can trust.

Practical Example:
Imagine an open-source project that traditionally relied on a single, trusted maintainer to manually review all security-sensitive code. To comply with the CRA, the steward formalizes this by creating a SECURITY.md file. This file publicly documents the security policy, names a security team, defines the review process, and provides a dedicated email for reporting vulnerabilities. The informal process is now a documented, transparent one.

The real goal of a secure-by-design policy is to make security a non-negotiable part of the development lifecycle. It embeds security thinking into every stage, from the initial concept to the final release, instead of treating it like an afterthought.

The good news is that many projects are already well on their way. A Linux Foundation report from early 2025 found that an impressive 74% of surveyed stewards already had security policies in place to manage cybersecurity issues. This high adoption rate in the ES region and beyond gives many stewards a head start as the CRA rolls out. You can dive into the data in the Linux Foundation’s CRA Readiness & Awareness Report.

Actionable Steps for Secure by Design

So, what does a “secure by design” policy look like in the real world? It boils down to a few concrete actions that weave security directly into your development workflow. As a steward, you’ll need to set up clear, repeatable processes for your most important security activities.

Here are a few practical steps you could take:

• Establish a Threat Modelling Routine: Before you build any major new features, create a process to identify potential security threats. For instance, your policy might demand a simple threat model for any pull request that touches authentication logic.
• Adopt Secure Coding Standards: Formally adopt and document a set of secure coding guidelines, like the OWASP Top 10. Make it clear that all contributors are expected to follow them.
• Mandate Security Reviews: Ensure all new code gets a security check before it’s merged. To make this work, Mastering Security Code Reviews: Your Practical Guide is an essential read for identifying and fixing risks before they become problems.

Practical Example:

Imagine you steward a popular data-processing library. You could update your contribution policy to say: “All pull requests must pass an automated static analysis security testing (SAST) scan and receive at least one manual code review from a designated security lead before being considered for a merge.” This one simple rule makes security an explicit, mandatory step.

A Safe Harbour for Good Faith Efforts

While these new policy obligations are mandatory, the CRA contains a critical provision known as a “safe harbour.” Article 64(10) specifically exempts stewards from administrative fines for non-compliance with these particular policy-related duties. This is a big deal. It encourages good-faith efforts without the fear of massive financial penalties for an imperfect process.

This exemption is designed to foster a culture of improvement, not punishment. The focus is on making progress, not achieving immediate perfection, which is a nod to the unique, community-driven nature of open-source development. You can get more details on building these practices in our guide to creating a secure software development life cycle.

Mastering Vulnerability Reporting and Disclosure

Of all the obligations the CRA places on open-source stewards, vulnerability management is where the stakes are highest. It’s the only area where stewards can face significant fines, making a clear, documented process completely non-negotiable. This is all about having a predictable system for handling security issues, from the initial report right through to the public fix.

The process demands several mandatory steps. If a steward finds out a vulnerability in their project is being actively exploited, they have to move fast. The clock starts ticking immediately, and the response must be both quick and well-coordinated.

The 24-Hour Reporting Mandate

The most urgent duty is the 24-hour reporting rule. Once a steward is aware that a vulnerability in their software is being actively exploited, they must notify the relevant authorities within 24 hours. This initial report goes to two key bodies:

• ENISA (The European Union Agency for Cybersecurity): The central EU body responsible for coordinating cybersecurity responses.
• The National CSIRT: The Computer Security Incident Response Team in the relevant EU member state. For a steward based in Spain, this would be INCIBE-CERT.

This first notification isn’t a deep technical analysis. Think of it as an immediate heads-up, giving authorities an early warning of a threat that could spread. This allows them to prepare for the wider impact across the ecosystem.

The core principle here is speed. The 24-hour window for reporting actively exploited vulnerabilities is strict. Stewards must have a pre-defined internal process to identify such incidents and escalate them to the correct channels without any delay.

After this initial alert, stewards have a follow-up duty. They must promptly inform their downstream users—the manufacturers putting the software into their products—and the wider community about the vulnerability and any fixes or workarounds. This ensures everyone in the supply chain can act to protect their own systems. A foundational step in mastering this is to perform a thorough vulnerability assessment to proactively find security weak points.

A Log4j-Style Incident Under the CRA

To make this real, let’s walk through a hypothetical incident similar to the Log4j crisis, but looking at it from the perspective of a CRA-compliant open-source steward.

1. Private Disclosure (Day 1): A security researcher privately reports a critical remote code execution (RCE) vulnerability to your project’s security team, using the contact info in your SECURITY.md file. Your team gets to work and validates the vulnerability.
2. Evidence of Exploitation (Day 5): While your team is developing a patch, you find credible online evidence that the vulnerability is now being actively exploited in the wild. The 24-hour clock starts now.
3. Mandatory Reporting (Day 6): Within 24 hours of discovering the active exploitation, you send an initial notification to ENISA and the relevant national CSIRT. The report briefly describes the vulnerability and confirms it’s being exploited.
4. Coordinated Disclosure (Day 10): After working with key downstream manufacturers under an embargo, you publicly release a patched version of the software. At the same time, you publish a security advisory with a CVE identifier, explaining the impact and giving clear instructions for upgrading.
5. Ongoing Cooperation: In the weeks that follow, you cooperate with market surveillance authorities, giving them the information they need to assess the market-wide risk. The focus is on technical details to help with mitigation, not on revealing sensitive internal data.

This structured response is a world away from the ad-hoc scramble many projects faced in the past. It turns incident response from a chaotic reaction into a defined, predictable workflow.

Vulnerability management is a cornerstone of the CRA for open-source software stewards. Stewards must report actively exploited vulnerabilities to ENISA and relevant CSIRTs, as laid out in Articles 11.3 and 11.8. A 2025 report shows that 68% of stewards already proactively identify and fix vulnerabilities, with 79% operating voluntary reporting channels. This is vital, as only vulnerability-handling obligations carry fines up to €15 million or 2.5% of global turnover. For IoT vendors in Spain facing 2027 deadlines, this high readiness from stewards is a huge help but requires tight integration for post-market surveillance.

For a deeper dive into what these reporting duties entail, you might be interested in our guide on CRA reporting obligations under Article 14.

Fulfilling Downstream Information Duties

Stewards sit at a critical junction in the software supply chain. The Cyber Resilience Act (CRA) makes it official: they have a responsibility to pass key security information down to the manufacturers who build products on top of their open-source projects. This information flow is the backbone of the transparent, secure ecosystem the CRA aims to build.

Think of it this way. While stewards are not on the hook for the full conformity assessments that manufacturers face, they must provide the raw data those manufacturers need to complete their own. A steward is like a supplier of a specialised flour; they don’t bake the final cake, but they absolutely must provide a detailed list of what’s in their flour so the baker can create an accurate ingredients label.

This formalises a process that ensures security information travels all the way from an open-source project to the end user.

Providing a Software Bill of Materials (SBOM)

A huge part of this transparency duty revolves around providing information for a Software Bill of Materials (SBOM). An SBOM is simply a formal, machine-readable inventory of every single component that makes up a piece of software, much like a list of ingredients for a recipe.

Under the CRA, manufacturers are mandated to create and maintain an SBOM for their products. To get this right, they need precise data from all their suppliers, and that absolutely includes open-source stewards. This is a central pillar of the CRA open source steward obligations.

The steward’s job is to supply this dependency information in a clean, usable format.

• What Stewards Must Provide: You should be ready to generate a machine-readable file listing your project’s direct dependencies, their exact versions, and any known security issues tied to them. Formats like SPDX or CycloneDX are the industry standard here.
• What Manufacturers Do With It: The manufacturer then pulls in this file, merges it with data from their other software components, and builds the complete SBOM for their final product.

Practical Example:
Imagine you’re the steward for a popular data visualisation library. A company making a business intelligence tool uses your library. To stay compliant, you provide a CycloneDX file with each release detailing that your library depends on “Parser v1.2” and “Connector v3.4.” The manufacturer’s build system automatically ingests that file, instantly updating their product’s master SBOM. If you later release a security patch for “Connector v3.4,” the updated SBOM file signals the manufacturer to take action.

This kind of seamless data exchange is what’s needed for real supply chain integrity. Unfortunately, the industry has a long way to go. Very few open-source projects currently produce comprehensive, machine-readable SBOMs consistently. This leaves manufacturers stuck with the painful and error-prone job of manually digging through code to identify dependencies. The CRA is designed to close this exact gap by making the steward’s role explicit.

Cooperating with Market Surveillance Authorities

Beyond just providing SBOM data, stewards also have a duty to cooperate with market surveillance authorities, like a national competent authority or a national CSIRT. This might sound intimidating, but the CRA frames it as a collaborative effort, not an adversarial audit. The shared goal is to work together to secure the entire digital market.

This cooperation usually kicks in when an authority makes a reasoned request for information. It’s not a blank cheque for them to demand all your project’s internal data. The request must be focused and necessary to assess or mitigate a specific, identified risk.

The duty to cooperate is about shared responsibility. Stewards hold crucial technical knowledge about their projects, and sharing that knowledge with authorities helps protect the entire ecosystem from widespread threats.

Practical Example:
If a major vulnerability is found in a widely used open-source networking protocol you manage, a market surveillance authority might ask for technical details on the flaw and which versions are affected. Your cooperation could involve providing a list of affected release hashes and technical guidance on how to detect exploitation attempts. This allows them to push out targeted alerts to critical infrastructure operators across the EU. Your cooperation is what makes that kind of rapid, coordinated response possible.

The flow from initial reporting to notification and finally to cooperation creates a structured response that puts the security of the ecosystem first.

Your Compliance Roadmap for 2026 and Beyond

With the Cyber Resilience Act’s main deadlines arriving in 2026 and 2027, compliance is becoming a strategic topic for everyone in the software supply chain. Both open-source stewards and the manufacturers who build on their work have clear, though different, paths to follow.

This roadmap connects the CRA’s expectations into a coherent plan for each role. For open-source stewards, this means formalising the security practices many already follow. For manufacturers, it’s about building the processes to consume, verify, and act on security information from your open-source dependencies.

A Three-Step Plan for Open-Source Stewards

The CRA asks stewards to move from informal community norms to documented, reliable processes. The aim isn’t to force a new workflow on you, but to structure your existing security efforts so that downstream manufacturers can depend on them. Your focus should be on creating transparent policies and predictable information channels.

1. Formalise Your Security Policies: First, create and publish a clear cybersecurity policy. This document is where you explain how your project handles security, from accepting code contributions to managing vulnerability reports. It sets expectations for everyone.
2. Establish a Clear Intake Process: You need a public, structured way to receive security reports. A SECURITY.md file in your repository is the perfect place to start. It should include contact details and a general idea of your response times.
3. Prepare to Provide Dependency Information: Get ready to supply manufacturers with the data they need for their Software Bill of Materials (SBOM). Start exploring tools that generate SBOMs in standard formats like CycloneDX or SPDX.

Practical Example for a Steward:
An open-source steward for a popular JavaScript library can start by drafting a simple markdown document for their vulnerability disclosure policy. They can then set up a dedicated email like security@project.org and list it in a SECURITY.md file in their main repository. This single action meets a core CRA expectation.

A Three-Step Plan for Manufacturers

As a manufacturer, you carry the final responsibility for any product you place on the EU market. Your compliance hinges on your ability to understand, document, and manage your entire software supply chain—especially its open-source parts.

• Inventory Your Open-Source Components: Your first job is to create a full and accurate inventory of all open-source software inside your products. You can’t secure what you don’t know you’re using.
• Identify Which Components Have a Steward: For each component on your list, figure out if it is managed by a recognised open-source steward. This tells you where you can expect to find structured security information and who to contact.
• Build an Ingestion Process: Set up a formal workflow to receive, process, and act on the security data that stewards provide. This means integrating their SBOM fragments into your product’s main SBOM and having a plan ready to deploy patches when they announce a vulnerability.

Practical Example for a Manufacturer:
A company that builds an IoT device could use an automated scanning tool to generate an initial SBOM for its firmware. By reviewing that list, they identify that their device’s operating system is managed by a major foundation (a steward). They would then set up an automated feed to monitor that foundation’s security advisories for any relevant patches.

Early and open communication between manufacturers and stewards is the most effective compliance strategy. It will significantly reduce last-minute costs, streamline your documentation efforts, and build a more secure software ecosystem for everyone involved.

Open Source and the CRA: Answering Your Top Questions

This section tackles some of the most common questions we hear about the Cyber Resilience Act’s impact on open-source projects, stewards, and individual developers.

Are Individual Open-Source Developers Liable Under the CRA?

No. If you’re an individual contributing code to an open-source project in your spare time, without any commercial intent, the CRA’s obligations don’t apply to you. The regulation makes a clear distinction to protect the non-commercial open-source community.

The rules for “stewards” kick in only for legal entities—like foundations or companies—that provide structured, ongoing support to open-source software that finds its way into commercial products on the EU market.

What Happens If a Steward Fails to Report a Vulnerability?

This is where the CRA has real teeth. A steward’s failure to report an actively exploited vulnerability within the mandatory 24-hour window is the one obligation that carries massive financial penalties.

If a steward fails to meet this reporting deadline, they could face a fine of up to €15 million or 2.5% of their total worldwide annual turnover, whichever is higher. Other duties, like maintaining a security policy, are still mandatory but don’t come with this specific penalty structure.

Do Stewards Need to Get a CE Mark for Their Software?

No, they don’t. Under the CRA, open-source stewards are not considered “manufacturers.” This means they are completely exempt from the conformity assessment process, creating an EU Declaration of Conformity, and applying a CE mark.

A steward’s job is to provide the security foundation and critical information. The actual manufacturer who integrates that software into a final product is the one responsible for the full conformity process and the CE mark.

How Does the CRA Affect Non-EU Open-Source Projects?

The CRA’s jurisdiction is tied to where a product is sold, not where the code is written. It’s all about access to the EU market.

If an open-source project is managed by a steward—regardless of their physical location—and is then integrated into a commercial product placed on the EU market, the steward’s obligations are triggered. For example, a US-based foundation that stewards a popular library used in a smart thermostat sold in Germany must comply with its CRA duties.

At Regulus, we provide a dedicated software platform to help you navigate the complexities of the Cyber Resilience Act. Our solution helps you assess applicability, map requirements, and generate the documentation needed to confidently place compliant products on the EU market. Gain clarity and reduce compliance costs by visiting https://goregulus.com.

La entrada CRA Open Source Steward Obligations Explained se publicó primero en Regulus.

Comparing CRA and RED High-Level Requirements

For businesses placing products on the EU market, navigating the cybersecurity requirements of the CRA versus RED can feel like untangling a complex web. The Radio Equipment Directive has long governed radio-enabled products, but the Cyber Resilience Act introduces a broader, more demanding security framework that now sits alongside it.

Understanding how they interact is the first step toward building a compliant product strategy that won’t get you into trouble with market surveillance authorities.

The RED’s cybersecurity articles—specifically 3.3(d), (e), and (f)—are focused on a narrow set of risks associated with radio devices. These articles zero in on preventing network harm, protecting personal data and privacy, and ensuring safeguards against monetary fraud. For instance, this means a Bluetooth speaker must not be designed in a way that could bring down a home Wi-Fi network.

In stark contrast, the CRA establishes a horizontal framework covering the entire lifecycle of any product with digital elements (PDE). It mandates a secure-by-design approach, ongoing vulnerability management, and transparent reporting, regardless of whether the product uses radio waves. A practical example here would be a children’s toy with a simple LCD screen and a button; even without connectivity, its firmware falls under the CRA’s security requirements.

Key Differences at a Glance

The main distinction boils down to their primary focus and the breadth of their applicability. While RED is vertical and targeted, the CRA is horizontal and all-encompassing.

The simplest way to look at it is this: RED is concerned with the risks created by a product’s radio connectivity, while the CRA is concerned with the overall cybersecurity resilience of the product itself. This means many modern devices will need to comply with both.

This breakdown offers a clearer comparison of the CRA vs RED cybersecurity requirements:

A practical example makes this crystal clear. A new smart watch uses Bluetooth, so its radio module falls directly under RED’s jurisdiction. This means the manufacturer must ensure the Bluetooth connection doesn’t disrupt other devices and that personal data transmitted over it is protected.

However, its operating system, the companion mobile app, and how it handles user health data are all governed by the CRA’s extensive security and reporting obligations. For example, under the CRA, the manufacturer must ensure the watch ships with a secure default configuration (no “1234” PIN), has a process for delivering security updates, and provides a Software Bill of Materials (SBOM) for its app. Manufacturers must therefore prepare for both regulatory frameworks simultaneously to ensure complete and undisputed market access.

Defining Product Scope and Applicability

Figuring out which regulation applies to your product is the first hurdle in securing EU market access. The line between the Cyber Resilience Act (CRA) and the Radio Equipment Directive (RED) comes down to a product’s core function and its digital components, so a detailed scope analysis isn’t just a good idea—it’s essential.

The RED’s cybersecurity articles are aimed at a very specific category: ‘radio equipment’. This means any product that intentionally sends or receives radio waves for communication or radiodetermination. If your device uses Wi-Fi, Bluetooth, 5G, or any other radio technology, it’s in the RED’s crosshairs. A practical example is a wireless microphone system; its sole purpose involves radio waves, placing it squarely under RED.

In contrast, the CRA’s net is cast far wider. It covers all ‘products with digital elements’ (PDEs), which is almost any piece of hardware or software that can process data, unless another law specifically carves it out. For instance, a USB stick with encryption software is a PDE and falls under the CRA, even though it has no radio components. You can get into the finer details of what counts as a PDE in our deep-dive on CRA applicability.

Differentiating RED and CRA Applicability

The fundamental difference is straightforward: the RED is vertical, targeting radio-specific risks. The CRA is horizontal, setting a baseline for the general cybersecurity of all digital products. This immediately creates an overlap where a huge number of modern connected products must comply with both.

For manufacturers, the clock is ticking. The RED Delegated Act (RED-DA) becomes mandatory on 1 August 2025, forcing all new radio equipment to meet Articles 3.3(d) for network protection, 3.3(e) for personal data privacy, and 3.3(f) for fraud prevention. This single deadline affects over 80% of connected products sold in the EU. Missing it means an immediate market lockout.

This simple decision tree clarifies how to determine if the CRA or RED applies based on a product’s digital makeup.

As the diagram shows, the moment a product has any digital component, it falls under the scope of either the CRA, the RED, or—very often—both.

The key takeaway is that the CRA establishes a foundational cybersecurity layer. Even if a product satisfies the RED’s radio-specific rules, it must also meet the CRA’s broader obligations for secure design, vulnerability management, and lifecycle support if it contains digital elements.

A Practical Example: A Smart Thermostat

Let’s break it down with a common IoT device: a smart thermostat.

• RED Applicability: Its Wi-Fi module, which it uses to connect to your home network and the internet, intentionally transmits and receives radio waves. This radio function is squarely in the RED’s scope and must comply with Articles 3.3(d), (e), and (f). This means ensuring its Wi-Fi connection is stable and doesn’t hog network resources in a harmful way.
• CRA Applicability: The thermostat’s operating system, the mobile app you use to control it, its connection to a cloud backend, and the mechanism for receiving firmware updates are all ‘digital elements’. These aspects fall under the CRA’s comprehensive requirements for secure development, vulnerability handling, and providing security patches. For example, the manufacturer must have a documented process for fixing a vulnerability discovered in the thermostat’s firmware and pushing an over-the-air update to all users.

This dual-track compliance is where many manufacturers get tripped up. The table below lays out the key differences in scope to help you map your obligations.

CRA vs RED At a Glance: Scope and Applicability

Understanding this dual applicability is critical. A single product often requires two parallel compliance efforts. You can’t assume that meeting the RED’s requirements is enough if your product also qualifies as a PDE under the Cyber Resilience Act.

Comparing Core Security Requirements

Once you get past the question of which regulation applies, the real work begins: understanding the specific security obligations each one imposes. The difference between the CRA and RED isn’t just in scope; it’s in their entire security philosophy.

The Radio Equipment Directive’s cybersecurity articles—3.3(d), (e), and (f)—are highly targeted. They focus on concrete outcomes: preventing network disruption, protecting personal data, and safeguarding against payment fraud. They define what a product must not do. For example, under 3.3(f), a connected point-of-sale terminal must incorporate features that prevent fraudulent payment transactions.

In contrast, the Cyber Resilience Act mandates a comprehensive, end-to-end security framework. It’s not just about preventing specific harms but about building and maintaining a resilient product from the ground up, covering the entire lifecycle. For that same point-of-sale terminal, the CRA would require the manufacturer to follow a secure coding process and provide security patches for its operating system for at least five years.

Secure by Design and by Default

A core principle of the CRA is that products must be secure by design and by default. This isn’t just a suggestion; it’s a legal mandate that makes security a foundational part of product development, not an afterthought.

In practice, this means manufacturers must integrate security from the earliest design phase. Key requirements include:

• Shipping products with secure default configurations, meaning no more universal “admin” passwords. For example, a new router must force the user to create a unique password during setup instead of using a default like “password123”.
• Minimising the attack surface by shipping with only essential functions and ports enabled. A smart TV, for instance, should have developer-mode ports disabled by default.
• Ensuring data is protected both at rest and in transit using appropriate encryption. A fitness tracker must encrypt the health data it stores on the device and when it syncs with a mobile app.

The RED doesn’t explicitly mandate a “secure by design” philosophy. Its requirements are more focused on the product’s final state when placed on the market. For example, a RED-compliant device must not harm the network, but the regulation is far less prescriptive about how a manufacturer achieves this during development.

Lifecycle Security From Development to Post-Market

This is where the CRA and RED diverge most sharply. The CRA’s obligations stretch far beyond the point of sale, demanding a formalised Secure Development Lifecycle (SDL). Implementing robust secure software development best practices becomes a non-negotiable part of compliance, involving activities like threat modelling, code reviews, and penetration testing.

You can dive deeper into these steps in our complete guide to building a CRA-compliant Secure Development Lifecycle (SDL).

Let’s take a connected security camera as an example:

• Under RED: The camera’s Wi-Fi module must not cause interference or disrupt networks. It also needs basic safeguards for the personal data it transmits (like the video stream).
• Under the CRA: The manufacturer must also prove it followed a secure development process. This means conducting threat modeling to identify potential attacks (like hijacking the video feed), performing code analysis to find bugs, and ensuring the camera can be securely updated. The camera has to ship without known exploitable vulnerabilities, feature a secure and reliable update mechanism, encrypt stored video footage, and be delivered without a default password like “1234.”

The CRA effectively codifies lifecycle security as a legal requirement. It transforms security from a static, pre-market check into a continuous, dynamic process of vigilance and maintenance.

Vulnerability Handling and SBOMs

The CRA’s detailed requirements for vulnerability handling and supply chain transparency are another major differentiator. The Act requires manufacturers to have a structured, public process for receiving and addressing vulnerability reports from security researchers and users.

More importantly, the CRA mandates the creation and provision of a Software Bill of Materials (SBOM)—a formal, machine-readable inventory of all software components and dependencies in a product. This is a direct response to the massive impact of supply chain attacks, where a single flaw in an open-source library can compromise thousands of downstream products. A practical example is a manufacturer of a smart fridge providing a list that shows it uses a specific version of the OpenSSL library for encryption, allowing customers to track vulnerabilities associated with that library.

While the harmonised standard EN 18031, which supports RED, mentions the need for an SBOM to monitor vulnerabilities, the CRA elevates it to a mandatory legal obligation. The contrast is stark:

This means that while a RED-compliant product might need patching if a public vulnerability is found, the CRA demands that the manufacturer have the entire infrastructure in place to proactively find, receive reports on, manage, and fix vulnerabilities throughout the product’s entire supported lifetime. A product’s cybersecurity obligations don’t simply vanish once it hits the market. This post-market phase is precisely where the differences between the CRA and RED become most stark. While the Radio Equipment Directive (RED) implies a need for ongoing security, the Cyber Resilience Act (CRA) makes it an explicit, legally binding responsibility.

The CRA fundamentally shifts the manufacturer’s role from passive observer to active guardian of a product’s security. It formalises the duty to maintain a strong security posture long after the initial sale, demanding a major operational overhaul for many organisations.

Security Updates and Product Lifecycles

One of the most significant mandates from the CRA is the provision of free and timely security updates. Manufacturers must supply patches for a product’s expected lifetime or, at a minimum, for five years after it is first placed on the market. This rule is designed to prevent products from becoming insecure liabilities over time. For example, a smart TV sold in 2026 must receive security patches for its operating system until at least 2031, free of charge.

For RED, the obligation is far less direct. A manufacturer must address known exploitable vulnerabilities to keep a product compliant, but the directive never specifies a minimum support period or mandates that updates must be free. The CRA closes this regulatory gap, making long-term support a non-negotiable condition for EU market access.

This heightened awareness of lifecycle duties is forcing urgent action. While RED awareness in the EU’s ‘ES’ region was a high 60% in 2023, awareness of the CRA’s deeper implications shot up from just 20% to 45% in a single year. Projections show CRA awareness will likely hit 70% by 2025, a rise driven almost entirely by its demanding lifecycle requirements. You can discover more insights about these trends and what they mean for the future on cclab.com.

Vulnerability Reporting and Coordinated Disclosure

This is where the CRA imposes a significant operational burden compared to the RED. The CRA requires a structured, transparent, and audited process for both receiving and handling vulnerability reports from external sources, like security researchers.

The CRA’s 24-hour reporting rule for actively exploited vulnerabilities is a game-changer. It forces manufacturers to have a well-oiled incident response machine ready to act at a moment’s notice, transforming vulnerability management from a background task into a critical, time-sensitive function.

Under the CRA, if a manufacturer confirms a vulnerability is being actively exploited, they have a strict 24-hour window to report it to ENISA (the European Union Agency for Cybersecurity). This is a world apart from the RED, which has no equivalent time-bound reporting mandate.

Consider a real-world scenario:

• The Situation: A smart door lock manufacturer discovers a critical firmware flaw that hackers are actively using to gain unauthorised entry.
• Under RED: The manufacturer would need to develop and issue a patch to maintain compliance, but there are no specific rules on how or when to notify authorities.
• Under the CRA: The manufacturer must not only create and deploy a patch but also notify ENISA of the actively exploited vulnerability within 24 hours. They are also obligated to inform their users about the threat and the available fix without undue delay.

This single requirement fundamentally changes how companies must prepare for security incidents. If you’re looking for more detail, you can learn more about the specific CRA reporting obligations and what they mean for your team. Building this proactive security posture requires a serious investment in both processes and people.

Navigating Conformity Assessment and Documentation

Proving compliance is just as important as achieving it, and this is where the paths for the Cyber Resilience Act (CRA) and the Radio Equipment Directive (RED) really start to split. The formal processes for declaring a product compliant—what we call conformity assessment—and the technical files needed to back up that claim are worlds apart.

For years, manufacturers of products under RED have had a relatively straightforward path. Most could perform a self-assessment, meaning they could internally check their product against Articles 3.3(d), (e), and (f), compile the technical file, and slap on the CE mark with their own Declaration of Conformity. For example, a maker of consumer Bluetooth headphones could conduct its own tests to verify compliance.

The CRA throws a spanner in those works. It brings in a more rigorous, risk-based model that completely changes the game.

The CRA’s Risk-Based Assessment Model

While the CRA does allow self-assessment for many products, it carves them up by risk level, creating entirely different routes to conformity. This adds a layer of complexity that just doesn’t exist in RED’s one-size-fits-all approach.

Products are now sorted into these categories:

• Default Risk Products: This is the bucket for the vast majority of consumer electronics and software. For a simple fitness tracker, manufacturers can stick with an internal control procedure (Module A), which feels a lot like the old RED self-assessment.
• Critical Class I Products: These are higher-risk products, all listed out in Annex III of the CRA. Examples include home automation controllers or network management systems. They often demand a third-party Notified Body to get involved, unless the manufacturer follows the relevant harmonised standards to the letter.
• Critical Class II Products: For the highest-risk gear, like hardware security modules (HSMs) or smart card readers, there’s no way around it. These products must undergo a third-party conformity assessment by a Notified Body. No exceptions.

This tiered system means a manufacturer’s journey to the CE mark can look drastically different from one product to the next.

The shift from RED’s broad self-assessment model to the CRA’s risk-based conformity paths is one of the biggest operational hurdles for manufacturers. A product that was previously self-declared for RED may now face costly and time-consuming third-party audits under the CRA.

Comparing Documentation Requirements

The difference in approach bleeds directly into the paperwork. The technical documentation needed for CRA versus RED cybersecurity requirements are night and day in terms of the detail you’ll have to provide. When it’s time to document your security controls, resources like a practical SOC 2 compliance checklist can offer a good structural starting point for demonstrating proof of compliance.

A RED technical file is pretty focused. It’s all about proving compliance with its specific articles, and usually includes:

• Test reports showing the product doesn’t mess with communication networks.
• Proof of safeguards for personal data and privacy.
• Paperwork on measures taken to stop monetary fraud.

The CRA’s technical file, on the other hand, is a much heavier lift. It needs to tell the complete, transparent story of your product’s entire security posture and lifecycle management. Key elements must now include evidence of a secure development lifecycle, detailed vulnerability management procedures, and a full Software Bill of Materials (SBOM). If you need to dig into the nuts and bolts of this new process, you can find more detail on the CRA conformity assessment procedures.

A Practical Example: A Home Automation Gateway

Let’s think about a smart home gateway—the kind that controls your locks, lights, and cameras.

Under RED, the manufacturer could simply self-declare its Wi-Fi and Zigbee radios as compliant. The technical file would centre on radio performance and the basic security measures tied to Article 3.3.

Now, under the CRA, this very same product gets classified as ‘Critical Class I’. Suddenly, the compliance path is a much steeper climb. The manufacturer now must:

1. Bring in a Notified Body for a third-party conformity assessment (unless they perfectly implement harmonised standards).
2. Put together an exhaustive CRA technical file that proves a secure development process was followed from start to finish. This would include evidence like threat modeling diagrams and penetration test reports.
3. Include a detailed SBOM listing every single firmware and software component, from the operating system kernel to the open-source libraries used in its web interface.
4. Document the entire process for handling and reporting vulnerabilities post-launch, including the contact point for security researchers.

This comparison really drives home how the CRA fundamentally raises the burden of proof. It moves the goalposts from a focused, self-managed process under RED to a comprehensive, often externally-audited system for any product the EU considers critical.

Building Your Unified Compliance Roadmap for 2026

With deadlines for both the RED Delegated Act and the Cyber Resilience Act looming, a unified compliance strategy has moved from a good idea to an absolute necessity. The key is to turn regulatory uncertainty into a structured, step-by-step plan.

This roadmap breaks down the complex comparison of CRA vs. RED cybersecurity requirements into a series of manageable actions.

Following this plan is your best bet for placing products on the EU market confidently, without staring down the barrel of costly delays or penalties.

Phase 1: Portfolio Assessment

Your first job is to get a complete, honest picture of your product portfolio. You need to map out precisely which products fall under the RED, which fall under the CRA, and—most commonly—which are caught by both.

Take a company that makes smart lighting systems and industrial sensors. Their Wi-Fi-enabled smart lights are clearly subject to both RED and CRA. The wired industrial sensors, however, only fall under the CRA, as they have digital elements but no radio interface. This initial inventory is the foundation for everything that follows.

Phase 2: Gap Analysis

Once you know which regulations apply to which products, you have to benchmark your current security practices against what RED and the CRA demand. Use the latest harmonised standards, like EN 18031 for RED, to pinpoint exactly where your processes fall short.

This analysis must cover your entire process, from your Secure Development Lifecycle (SDL) all the way to your post-market vulnerability handling. For example, a practical step is to review your current product development handbook and see if it includes mandatory security checkpoints like threat modeling or static code analysis. If not, that’s a major gap. The goal is to walk away with a concrete list of deficiencies that need fixing to satisfy both regulations.

A thorough gap analysis is what separates the prepared from the panicked. It turns dense regulatory text into a practical to-do list, showing you exactly where to invest your resources for maximum impact before the 2026 and 2027 deadlines hit.

For example, you might find your development team doesn’t have a formal threat modelling process, a non-negotiable part of the CRA’s secure-by-design mandate. Or you might realise your RED-focused vulnerability response plan can’t meet the CRA’s strict 24-hour reporting window for actively exploited flaws.

Phase 3: Product Classification

With your list of CRA-applicable products in hand, the next critical step is to determine their risk classification. This is a major fork in the road because it dictates your entire conformity assessment path.

You have to categorise each product into one of two buckets:

• ‘Default’ Risk: The vast majority of products will land here. These can go through an internal self-assessment.
• ‘Critical’ Risk (Class I or II): These products, which are listed in Annex III of the CRA, demand a third-party assessment from a Notified Body.

A smart speaker might be deemed ‘Critical’, forcing you into expensive third-party audits. In contrast, a simple connected toothbrush would almost certainly be ‘Default’. Getting this wrong can invalidate your CE marking and lead to a forced market withdrawal.

Phase 4: Process Implementation and Documentation

This is where the plan becomes action. Using your gap analysis as a guide, you must establish and formalise the required procedures. This means implementing a robust SDL, creating a public-facing vulnerability disclosure policy, and setting up an incident response team that can meet ENISA’s reporting timelines. A practical first step could be to create a “security@company.com” email address and a documented procedure for how incoming reports are triaged, verified, and escalated.

At the same time, you need to start compiling the mountain of technical documentation required by both regulations. Begin gathering your Software Bill of Materials (SBOM), evidence from security testing, and the detailed justifications for your risk assessments. Assembling this documentation proactively is the key to a smooth conformity assessment and makes you ready for any inspection by market surveillance authorities.

Frequently Asked Questions About CRA and RED

When comparing the Cyber Resilience Act and the Radio Equipment Directive, manufacturers often run into the same critical questions. Here are the clear, operational answers you need.

If My Product Is RED Compliant, Do I Need to Worry About the CRA?

Yes, without a doubt. Achieving compliance with RED Articles 3.3(d), (e), and (f) is a necessary step, but it’s only a starting point. The CRA introduces a completely new set of obligations that span the entire product lifecycle, areas the RED simply doesn’t cover.

Think of it this way: your smart home hub’s RED compliance ensures its radio functions correctly and doesn’t interfere with other networks. The CRA, however, governs the security of its operating system, mandates it ships without guessable default passwords, and requires you to provide security updates for a minimum of five years. Your RED assessment is a foundation, but it must be supplemented with a full CRA assessment.

RED compliance covers specific, point-in-time radio security risks. The CRA demands continuous cybersecurity resilience for the entire product and its software components. One does not replace the other.

What Is the Difference Between a Default and a Critical Product Under the CRA?

The CRA classifies products into risk-based tiers, and the main difference is how you prove conformity.

• ‘Default’ products are the standard classification, covering the vast majority of consumer electronics and software. For these, manufacturers can typically perform a self-assessment against harmonised standards. A video game or a photo editing software would be a clear example.
• ‘Critical’ products (split into Class I and Class II) carry higher security implications. Think industrial controllers, network hardware, or home assistants with privileged access. These products demand a more rigorous conformity assessment, which almost always involves a third-party Notified Body.

A connected toothbrush is a perfect example of a ‘Default’ product. In contrast, a networked industrial pump controller that could impact critical infrastructure would almost certainly be classified as ‘Critical’, mandating a costly and time-consuming external audit before it can receive its CE mark.

How Can I Prepare for Both RED and CRA Deadlines Effectively?

The most effective strategy is to treat compliance as a single, unified project and start immediately. Use the nearer RED deadline as a catalyst to build foundational security practices that will also satisfy your future CRA obligations.

Your first move should be a gap analysis against harmonised standards that bridge both regulations. From there, focus on implementing a Secure Development Lifecycle (SDL) and establishing a formal, documented vulnerability management process. For example, start by generating an SBOM for one of your flagship products using an open-source tool. This practical exercise will reveal supply chain risks and prepare you for the CRA’s mandatory SBOM requirement. This approach breaks the monumental task into a manageable, step-by-step plan, ensuring you meet the RED deadline while being well-prepared for full CRA enforcement.

Navigating these complex regulations can be daunting. Regulus provides a clear path forward, generating a tailored requirements matrix and ready-to-use templates to streamline your CRA compliance journey. Gain clarity and confidently place your products on the EU market by visiting https://goregulus.com.

La entrada CRA vs RED Cybersecurity Requirements: A Clear Comparison for 2026 se publicó primero en Regulus.

The core difference boils down to what each piece of legislation protects. NIS2 is about securing the operational continuity of essential services—think energy grids, banks, and digital infrastructure. The CRA, however, focuses on securing the digital products themselves, like software and connected devices.

Untangling EU Cybersecurity: The CRA vs. NIS2

While both the CRA and NIS2 aim for a more secure digital Europe, they don’t overlap as much as you might think. They are complementary, tackling cybersecurity from opposite ends of the spectrum: one focuses on the organisations providing critical services, the other on the manufacturers building the products those organisations use.

The NIS2 Directive: Securing Critical Service Operations

The NIS2 Directive is all about the resilience of organisations that are vital to our economy and society. It imposes strict security and reporting obligations on entities in sectors like healthcare, transport, and finance to ensure they can withstand and recover from cyber incidents.

For example, a large Spanish hospital is designated an ‘Essential’ entity under NIS2. This means its management team is legally responsible for implementing risk management measures like multi-factor authentication, training staff on phishing, and reporting significant service disruptions (like a ransomware attack taking its patient system offline) to national authorities. NIS2 is concerned with how the hospital operates securely day-to-day.

The Cyber Resilience Act (CRA): Securing Products by Design

In contrast, the Cyber Resilience Act (CRA) is a regulation targeting the security of “products with digital elements.” This covers a huge range of tangible and intangible goods, from smart home devices and industrial controllers to standalone software. If you manufacture, import, or distribute a connected product for the EU market, the CRA applies to you.

To understand how it works in practice, let’s go back to that Spanish hospital. The manufacturer of a networked medical imaging machine used by the hospital must comply with the CRA. This means designing the machine to be secure from the ground up (e.g., no default passwords), providing security updates for its entire lifecycle, and reporting actively exploited vulnerabilities within 24 hours. The CRA is about ensuring the product itself is secure by design and remains so over time. For more background, you can learn about the Cyber Resilience Act in our detailed guide.

The core distinction is clear: NIS2 compels service providers to maintain robust cyber defences for their operations, while the CRA forces product manufacturers to build and maintain secure products throughout their lifecycle.

Core Differences Between CRA and NIS2 at a Glance

This table offers a high-level summary of the key distinctions between the two frameworks, highlighting their different targets, objectives, and scope.

Ultimately, an organisation might fall under both. A cloud provider, for instance, is an ‘Important’ entity under NIS2 and must secure its operations. If it also develops software that customers install (like a desktop sync client), that software product would need to comply with the CRA. The two regulations work in tandem to secure both the services we rely on and the products that power them.

Determining Your Scope and Applicability

Figuring out where you stand with the CRA and NIS2 starts with one crucial question: does your organisation make something, or does it do something? This is the fundamental difference in logic between the two frameworks, creating separate paths for product manufacturers and service providers.

This simple decision tree gets right to the point. Are you providing a service in a critical sector, or are you building a digital product for the market?

As you can see, NIS2 targets the operators of essential and important services. The CRA, on the other hand, zeroes in on the manufacturers of the very products those operators might be using.

How NIS2 Defines Its Scope

The NIS2 Directive identifies entities based on two straightforward criteria: their sector and their size. It lays out explicit lists of 18 sectors, splitting them into ‘Essential’ and ‘Important’ categories.

• Essential Entities: This covers the big ones—organisations in energy, transport, banking, health, and digital infrastructure.
• Important Entities: This category includes other vital sectors like postal services, waste management, and the manufacturing of certain critical goods.

Beyond the sector, NIS2 applies a simple size-cap rule. The directive generally targets medium and large organisations, which means those with over 50 employees or an annual turnover exceeding €10 million. For a practical example, a small, family-owned logistics company with 20 employees would likely be exempt, but a large national postal service falls squarely within the scope as an ‘Important’ entity.

The CRA’s Product-Focused Approach

The Cyber Resilience Act (CRA) comes at this from a completely different angle. It applies horizontally to nearly all ‘products with digital elements’ placed on the EU market. This is a massive net, catching everything from hardware like IoT devices to software like operating systems or mobile apps.

Crucially, the CRA’s applicability has no company size or revenue threshold. A two-person startup in a garage developing a smart thermostat app is just as subject to CRA rules as a multinational corporation building enterprise software. If you make it and sell it in the EU, the CRA applies.

This product-centric versus service-centric divide creates some very clear lines. Take a large German hospital, for instance. It’s an ‘Essential’ entity under NIS2 and is responsible for its own operational cybersecurity. But the manufacturer of the networked infusion pumps that hospital uses? They must comply with the CRA to ensure the pumps themselves are secure by design. You can dig deeper into these specifics by exploring our guide on Cyber Resilience Act applicability.

This distinction is especially sharp in markets like Spain, where regulatory alignment is vital for market access. While NIS2 targets an estimated 1,200 entities in Spain’s key service sectors, the CRA’s universal approach impacts a much broader base. It directly affects the country’s 45,000+ IoT-related enterprises, from multinationals down to the smallest startups, all of which now face immediate product security obligations and must prepare for CE marking requirements by 2027.

Whether your obligations fall under the CRA, NIS2, or both, the first step is always understanding your assets and risks. Using a comprehensive cybersecurity risk assessment checklist is a solid starting point for building out your compliance strategy.

Understanding Your Reporting Obligations and Timelines

When an incident strikes, the clock starts ticking. One of the most significant differences between the CRA and NIS2 is what triggers that clock and how you must respond. These reporting timelines aren’t just procedural details; they define your organisation’s response under pressure and shape your entire incident management strategy.

At a high level, NIS2 is reactive to service disruptions, while the CRA is proactive about product vulnerabilities. For a practical example, think of a major cloud provider, an ‘Essential Entity’ under NIS2, suffering a widespread outage that takes its customers offline. NIS2 gives them 24 hours to submit an ‘early warning’ to their national Computer Security Incident Response Team (CSIRT). This is then followed by a more detailed incident notification within 72 hours.

The CRA’s timeline, however, is triggered by a completely different event.

Different Triggers for the 24-Hour Clock

The CRA’s focus is squarely on product security, specifically when a flaw becomes an active threat. For a manufacturer, the 24-hour reporting duty begins the moment they become aware of an actively exploited vulnerability within their product. This is a critical distinction from NIS2.

Let’s take a practical example. A company manufacturing smart thermostats discovers a flaw in their firmware that attackers are actively using to gain control of devices and join them to a botnet. Under the CRA, they must notify ENISA (the EU Agency for Cybersecurity) and their national CSIRT within 24 hours. The report is about the vulnerability itself, not necessarily any resulting service disruption. We cover this in more detail in our overview of CRA reporting obligations under Article 14.

Key Takeaway: For NIS2, the trigger is a significant incident affecting service continuity. For the CRA, it’s the discovery of an actively exploited vulnerability in a product, demanding rapid, coordinated disclosure to prevent widespread harm.

This difference in triggers really highlights how the two frameworks complement each other. The CRA pushes manufacturers to report and fix exploitable flaws before they can be used to cause the large-scale service disruptions that would then trigger NIS2 reporting.

A Practical Comparison of Reporting Timelines

Getting the reporting timelines right is a common point of confusion, so let’s break down the practical differences. The table below highlights the key differences in what triggers a report, how quickly you must act, and who you need to inform.

CRA vs NIS2 Reporting Requirements At A Glance

While both mandates have a 24-hour deadline, the substance of the report and the required follow-up steps are quite different. As you work to define your incident response plans, it’s also helpful to be aware of global best practices and specific regional requirements, such as those related to cybersecurity incident reporting obligations.

Ultimately, these distinct triggers and timelines require tailored workflows. A product security team must have a process ready for the CRA’s exploited-vulnerability trigger, which is fundamentally different from the broader service-outage focus of NIS2.

Comparing Compliance Paths and Enforcement Penalties

The path to proving compliance—and the penalties for getting it wrong—is where the CRA and NIS2 diverge most sharply. How you demonstrate your security posture is entirely different under each framework.

NIS2 relies on national oversight of your internal processes. The CRA, on the other hand, uses an established EU-wide product conformity framework. Getting this distinction right is critical.

The NIS2 Path: Proving Internal Resilience

For NIS2, the journey is internal and process-driven. As a directive, it is transposed into national law, meaning each Member State enforces it through its own authorities. Compliance means demonstrating robust internal governance, conducting regular risk assessments, and proving board-level accountability.

Under NIS2, an organisation proves compliance by showing, not just telling. National authorities will conduct audits and demand evidence that your security measures are actually in place and working.

Take a large logistics company in Spain, classified as an ‘Important’ entity. Its compliance path would involve:

• Developing and maintaining a comprehensive risk management policy.
• Conducting annual security audits performed by an independent third party.
• Running mandatory training programmes for all employees on cybersecurity hygiene.
• Demonstrating to national auditors that its board of directors has formally approved and oversees its cybersecurity strategy.

Failure to meet these obligations can bring significant fines from national authorities, reaching up to €10 million or 2% of the company’s total global annual turnover, whichever is higher.

The CRA Path: Proving Product Security via CE Marking

The Cyber Resilience Act, as a regulation, is directly applicable across the entire EU without national transposition. It cleverly piggybacks on the well-established New Legislative Framework (NLF), using the CE marking process as its compliance mechanism. This applies a familiar product-safety process to the world of cybersecurity.

The CRA essentially says, “If your product has a digital element, its cybersecurity is now a matter of public safety, just like its electrical or mechanical safety.” It must earn its CE mark by proving it is cyber-resilient.

For a manufacturer, this creates a clear, product-focused path:

1. Conduct a Conformity Assessment: The manufacturer assesses the product against the CRA’s security requirements. For most products, this can be a self-assessment, but higher-risk products demand a third-party notified body.
2. Create Technical Documentation: This file must contain everything from the risk assessment and a Software Bill of Materials (SBOM) to evidence of a secure development lifecycle.
3. Issue an EU Declaration of Conformity: The manufacturer formally declares that the product meets all CRA requirements.
4. Affix the CE Mark: Only then can the product be legally placed on the EU market.

This compliance and enforcement model has huge implications for Spain’s digital product teams. While NIS2 impacts around 8,000 important entities in Spain through nationally transposed laws, the CRA directly hits Spain’s 30,000+ software and firmware makers with its CE marking mandate, completely bypassing company size thresholds.

Enforcement also diverges sharply. CRA violations are policed by Market Surveillance Authorities who can order product recalls and impose EU-wide fines of up to €15 million or 2.5% of global annual turnover—potentially exceeding NIS2 penalties. You can discover more insights about these contrasting frameworks on holmsecurity.com.

For instance, a French company developing a smart home security camera must create a full technical file, prove it has a process to deliver security updates for at least five years, and then affix the CE mark. If a Market Surveillance Authority in Germany later finds the product non-compliant, it can be pulled from shelves across all 27 EU member states.

Navigating the Intersection of CRA and NIS2

Although the Cyber Resilience Act (CRA) and the NIS2 Directive target different things—products versus services—they are not independent. The two frameworks were designed to be complementary, creating a strong, interlocking set of security obligations that reinforce one another across the EU market.

For organisations caught in the middle, understanding this intersection is essential for managing dual obligations and turning complex compliance work into a clear market advantage.

The most important point of overlap is supply chain security. Under NIS2, critical entities have a legal duty to secure their supply chains. The CRA, in turn, provides the very mechanism for them to do just that.

The NIS2 Demand for CRA-Compliant Products

NIS2 forces Essential and Important entities to meticulously vet the security of their suppliers. This single requirement transforms CRA compliance from a manufacturer’s internal problem into a key procurement criterion for a huge market of critical service providers.

Take a practical example: a large Spanish power plant, an ‘Essential’ entity under NIS2, must verify the cybersecurity of its operational technology. When its procurement team needs a new industrial control system (ICS), they won’t just evaluate performance and price; they will demand proof of security.

The manufacturer of that ICS falls directly under the CRA. They are obligated to:

• Build the ICS according to secure-by-design principles.
• Provide a Software Bill of Materials (SBOM) listing all its software components.
• Commit to providing security updates for a defined support period.
• Affix the CE mark as proof of CRA conformity.

This creates an incredibly powerful market dynamic. The power plant will use the manufacturer’s CRA compliance—proven by the CE mark and technical documentation—to fulfil its own NIS2 supply chain security obligations. In practice, NIS2 entities will become major drivers of CRA adoption, creating a strong market preference for CRA-compliant products.

The intersection creates a clear value chain: NIS2 entities must manage supply chain risk, and they will do so by demanding CRA-compliant products. For manufacturers, CRA compliance is no longer just a regulatory hurdle; it’s a market access key.

When One Organisation Has Dual Obligations

Another critical scenario involves organisations that are simultaneously NIS2 entities and CRA manufacturers. This is especially common for digital service providers, particularly Software-as-a-Service (SaaS) companies.

Think about a cloud-based electronic health record (EHR) provider based in Germany. This company is both:

• An ‘Essential’ NIS2 entity because it provides a critical service to the healthcare sector.
• A ‘manufacturer’ under the CRA because it develops and commercialises the EHR software product.

Here, a single security event can trigger obligations under both frameworks. Imagine the company’s security team discovers an unpatched, actively exploited vulnerability in the EHR software’s code that allows unauthorized access to patient data.

1. CRA Obligation Triggered: Because the flaw is actively exploited, the provider must notify ENISA within 24 hours, as required by the CRA.
2. NIS2 Obligation Triggered: If this same vulnerability causes a data breach or service disruption for its hospital clients, it becomes a ‘significant incident’. This triggers the 24-hour early warning and 72-hour detailed incident report required by NIS2.

This dual-trigger scenario shows why a unified compliance strategy is non-negotiable. For organisations in this position, managing product vulnerabilities and operational incidents are two sides of the same coin. The European Commission has provided guidance on this topic, and you can learn more about how to prepare from our analysis of CRA implementation guidance. Ultimately, successfully navigating these overlapping requirements demands a clear understanding of both your role as a service provider and your responsibilities as a product manufacturer.

Developing a Unified Compliance Strategy

Trying to manage CRA and NIS2 requirements with separate spreadsheets and disconnected processes is a recipe for duplicated work. A unified strategy is the only practical way forward, helping you treat both regulations as a single, interlocking compliance challenge instead of two separate problems.

This approach starts with a clear mapping of your obligations. A guided applicability assessment, for example, can immediately clarify whether the CRA, NIS2, or both apply to your products and your customers, giving you a solid starting point.

From Rules to a Roadmap

Once you’ve established applicability, the next step is translating dense legal text into a concrete plan of action. This means generating a requirements matrix based on your product’s specific classification—whether it falls under the default rules or a higher-risk class. This matrix should map specific obligations from the CRA Annexes and give you actionable templates.

For instance, if you manufacture a smart home router, a unified platform can generate a checklist covering:

• Annex I Security Requirements: Specific secure-by-design principles you must implement, like ensuring encrypted communication and having a secure update mechanism.
• Vulnerability Handling Processes: Templates for documenting how you will manage and report discovered vulnerabilities.
• Technical Documentation: A structured outline for your EU Declaration of Conformity and the supporting evidence files.

This turns vague regulations into a concrete roadmap for achieving compliance by the 2026–2027 deadlines.

By centralising documentation, managing vulnerability disclosures, and tracking supplier compliance in one place, you can build a single, efficient programme that satisfies both product and service security demands, ensuring you can confidently serve the EU market.

An Integrated Compliance Example

Consider a SaaS company that provides logistics software to large shipping companies. This company faces dual obligations:

• As a NIS2 ‘Important’ entity: It must secure its own operations and service delivery.
• As a CRA ‘manufacturer’: Its software product must meet CRA’s security-by-design and lifecycle requirements.

Instead of running two parallel compliance projects, a unified approach allows them to use the same evidence for both. The secure software development lifecycle (SSDLC) process documented for CRA compliance also serves as proof of a key risk management measure required under NIS2.

Likewise, the vulnerability disclosure process mandated by the CRA becomes a core component of their NIS2 incident response plan. When a single platform like Regulus manages both the product-level requirements (CRA) and the operational security evidence (for their NIS2 customers), the company avoids duplicating effort. This not only reduces costs but also builds a more robust and defensible security posture across the board. The key is to see the CRA vs NIS2 differences not as a conflict, but as an opportunity for integrated efficiency.

Frequently Asked Questions About CRA and NIS2

The relationship between the Cyber Resilience Act and the NIS2 Directive often creates confusion, especially where their obligations seem to overlap. Here are some straightforward answers to the most common questions we hear from manufacturers and digital service providers.

If My Product Is CRA Compliant, Do I Still Need to Worry About NIS2?

Yes, absolutely. Think of it this way: CRA compliance is about the security of your product. NIS2 is about the operational security of the entity using it.

For a practical example, if you sell your CRA-compliant product to a hospital (an ‘Essential’ entity under NIS2), they have their own separate obligations. Specifically, they must manage their supply chain risks. Your CRA compliance—proven by your CE mark and technical documentation—becomes a critical piece of evidence they will need from you to meet their regulatory requirements. Your job is to provide the secure product; their job is to use it securely as part of their broader operations.

Can I Be Fined Under Both CRA and NIS2 for the Same Event?

It is possible, particularly if you are a dual-status organization. Imagine you’re a SaaS provider for the banking sector. A severe security flaw in your software would be a clear CRA violation. If that flaw leads to a major service disruption that prevents customers from accessing their accounts, that disruption could be classed as an NIS2 incident.

Because the two regulations address different failures—the insecure product (CRA) and the disrupted service (NIS2)—you could theoretically face penalties under both for a single root cause.

Which Regulation Has Stricter Penalties?

On paper, the CRA has higher maximum financial penalties. Fines can reach up to €15 million or 2.5% of global annual turnover, whichever is greater.

NIS2 penalties are capped slightly lower, at €10 million or 2% of turnover. However, focusing only on the numbers is a mistake. Both regulations grant authorities serious enforcement powers, from ordering product recalls (CRA) to issuing legally binding instructions (NIS2).

Key Takeaway: While the CRA’s fines are nominally higher, the enforcement powers under both regulations are severe and designed to compel compliance. The biggest risk isn’t just the fine; it’s the operational chaos from a product recall or a binding order from a supervisory authority.

What Is the Most Significant Difference for a Product Manufacturer?

For a product manufacturer, the biggest difference lies in the compliance mechanism itself. The CRA mandates compliance through the EU’s established CE marking framework. This means you must conduct a conformity assessment, compile a comprehensive technical file with a Software Bill of Materials (SBOM), and physically affix the CE mark to your product before it can be legally sold in the EU.

NIS2, on the other hand, is primarily about internal processes, risk management, and governance. These obligations fall mainly on your customers (the service providers), not directly on you as the manufacturer, though they will push those requirements down to you via their procurement process.

Navigating CRA and NIS2 requires a clear, actionable plan. Regulus provides a guided platform to assess your applicability, map requirements, and generate the evidence needed for CRA compliance. Gain clarity on your obligations and build your roadmap today.

La entrada CRA vs NIS2 Differences A Guide to EU Cyber Compliance in 2026 se publicó primero en Regulus.

Understanding Your Core CRA Update Obligations

The Cyber Resilience Act isn’t just another box-ticking exercise. It fundamentally changes how you must manage product security long after a sale is made, shifting security support from a customer service perk to a core compliance mandate. This has serious implications for your budgeting, engineering resources, and long-term product strategy.

At its heart, the CRA establishes a legally binding minimum security support window. For any product with digital elements you place on the EU market, you are obligated to provide security updates for a minimum of five years.

For instance, if your company launches a new smart home hub in June 2027, your team must be prepared to actively develop and deploy security patches for it until at least June 2032. This isn’t about shipping new features; it’s a firm commitment to patch discovered vulnerabilities for that entire period.

Your security update and EOL policy is where you make this commitment transparent and formal. Below is a summary of the key elements your policy must contain to align with CRA expectations.

CRA Security Update Policy Key Elements

This table covers the non-negotiables. Building your policy around these components ensures you’re not just compliant on paper but also ready to execute when a vulnerability is found.

Defining the Five-Year Support Window

The five-year clock starts the moment a product is “placed on the market.” This is a legally binding obligation that went into force on 10 December 2024, with its main requirements becoming applicable from 11 December 2027. Article 13 of the CRA is clear: manufacturers must handle vulnerabilities effectively throughout the support period, and patches must be provided “without delay.”

So, if you place a product on the EU market in 2028, you must maintain an active security update infrastructure for it until at least 2033. It’s a simple rule with complex operational consequences.

Beyond the Five-Year Minimum

Don’t get too comfortable with the five-year rule. It’s a floor, not a ceiling. The CRA requires the support period to align with the product’s expected lifetime and reasonable user expectations. This is where you need to apply some critical judgement.

A key takeaway is that the ‘expected product lifetime’ isn’t determined by your marketing department, but by a realistic assessment of how long a consumer or business will actually use the device.

Let’s look at a few real-world scenarios:

• Smart Thermostat: A consumer who has a smart thermostat professionally installed in their home will reasonably expect it to function securely for seven to ten years, not just five.
• Industrial PLC (Programmable Logic Controller): In a factory, these controllers often have operational lifespans of 15 years or more. A five-year security policy here would be seen as grossly insufficient and non-compliant.
• Consumer Drone: Given the rapid pace of technological change and the likelihood of physical wear and tear, a five-year support window might be perfectly reasonable.

Failing to align your support period with these realistic expectations is a direct path to non-compliance penalties and a breakdown in customer trust. To meet these mandates effectively, it’s vital to build a broader framework for regulatory compliance risk management. For a deeper dive, check out our guide on CRA update requirements for more detailed information. This strategic planning ensures your policy is not only compliant but also a tool for building long-term trust.

An EOL security updates policy isn’t a document you write once and file away. For CRA compliance, it has to be a living, operational workflow. This is where the theory ends and the real work of building your vulnerability detection, management, and disclosure processes begins.

Your first move is to establish clear and secure reporting channels. Under the CRA, security researchers are your allies, not adversaries. You need to give them an easy, reliable way to tell you about potential vulnerabilities.

A common and effective way to do this is with a security.txt file on your website. This simple text file acts as a signpost, directing researchers to your vulnerability disclosure policy (VDP) and the right email address. For example, your security.txt file should point to a contact like security@yourcompany.com and include a link to your public VDP page.

Establishing Internal Triage and Prioritisation

Once a vulnerability report lands in your inbox, your internal workflow must take over. Not all vulnerabilities are created equal, which is why a structured triage process is so important. This is where you assign severity scores—usually with the Common Vulnerability Scoring System (CVSS)—and prioritise what to fix based on real-world risk.

A solid, repeatable workflow might look like this:

• Initial Triage: An assigned security team member acknowledges the report within 48 hours. Their first job is to validate the report to confirm it’s a genuine vulnerability affecting your product. For example, if a researcher claims they can bypass the login on your smart lock app, the triage team’s first job is to try and replicate that exact process.
• Severity Assessment: The team assigns a CVSS score and classifies the vulnerability (e.g., Critical, High, Medium, Low). A remote code execution flaw in your core firmware is obviously Critical; a minor glitch in the UI is Low.
• Prioritisation: Based on its severity, the vulnerability is fed into the engineering backlog. Critical issues must jump to the front of the queue, no questions asked.

This entire triage process has to be documented. When regulators come knocking, they’ll want to see evidence of a repeatable, risk-based system for handling vulnerability reports. For a much deeper dive into these mechanics, you can read more about https://goregulus.com/cra-requirements/cra-vulnerability-handling/.

Defining and Documenting Your SLAs

With a vulnerability prioritised, the clock on your Service Level Agreements (SLAs) officially starts. The CRA’s requirement to provide updates “without delay” is intentionally vague; your policy is where you translate that into concrete, defensible timelines. These SLAs are your public commitment to patching.

The CRA reporting obligations, which became effective on 11 September 2026, force manufacturers to have these processes documented and ready for inspection. This deadline arrives well before the main obligations in December 2027. Your technical files must prove you can support your products for the required five-year period and respond to incidents, all underscoring the urgency of delivering updates “without delay.”

The timeline below shows the mandatory support period that every product must follow.

As you can see, the five-year security support clock starts the moment your product is launched. This is a commitment that must be actively managed until you formally declare its End of Life.

Defining your response timelines is a critical exercise. The following table provides a template for defining your internal and external SLAs based on vulnerability severity, which is a cornerstone of a compliant CRA policy.

Sample Vulnerability Response SLAs

This structure creates an auditable, risk-based process that demonstrates your commitment to timely remediation and helps you meet those crucial reporting deadlines.

Differentiating Default vs. Critical Product Timelines

The CRA isn’t a one-size-fits-all regulation. It distinguishes between product classes, and your SLAs absolutely must reflect that. ‘Critical’ class products—think industrial controllers, network hardware, or safety systems—carry far greater systemic risk and are held to a much higher standard.

A key principle is that the more integral your product is to critical infrastructure or operations, the shorter your patching timeline must be. Your CRA end of life security updates policy must reflect this risk-based approach.

Your workflow needs to account for the heightened urgency around critical security vulnerabilities, as recent incidents have shown how quickly these can escalate.

Let’s look at a practical comparison of SLAs for two different types of products. A ‘Default’ class smart speaker just doesn’t carry the same weight as a ‘Critical’ class Programmable Logic Controller (PLC) used in a factory.

• For a Critical vulnerability (CVSS 9.0+):

  • ‘Default’ Smart Speaker: You might commit to a patch within 30 days. An example would be a flaw allowing unauthorized access to the speaker’s microphone.
  • ‘Critical’ PLC: The expectation is much shorter, perhaps 15 days or even less. A similar remote access flaw in a PLC controlling a city’s water pumps would demand a much faster response.

• For a High severity vulnerability (CVSS 7.0-8.9):

  • ‘Default’ Smart Speaker: A 60-day patch timeline might be acceptable.
  • ‘Critical’ PLC: You’d be expected to deliver a patch within 30 days.

Building this tiered, risk-based workflow isn’t just a good idea; it’s a non-negotiable requirement for market access under the CRA. It creates the repeatable, auditable process you need to prove your vulnerability management is both effective and compliant.

Drafting Your Policy Document Clause by Clause

Alright, let’s get practical. It’s time to translate your plans into a formal, actionable document. Your CRA end of life security updates policy isn’t just a box-ticking exercise for the lawyers; it’s a public promise to your supply chain partners and the people who use your products. This document has to be precise, transparent, and leave zero room for interpretation.

Think of this policy as the single source of truth for your product’s security lifecycle. It spells out your commitments, manages expectations, and gives you a framework for handling vulnerabilities and communicating updates. Every clause needs to be written with both compliance and real-world clarity in mind.

Defining Policy Scope and Applicability

First up, you need to be crystal clear about which products the policy actually covers. This is especially critical if you have a large or growing product portfolio. Getting specific here prevents a world of confusion down the line for everyone from your internal teams to distributors.

The best way to do this is by listing product families or even specific models. Vague, all-encompassing language is a recipe for trouble.

Here’s how that might look in a real policy:

“This Security Update and End-of-Life Policy applies to all hardware and software products with digital elements manufactured by [Your Company Name] and placed on the European Union market on or after December 11, 2027. This includes, but is not limited to, the ‘SmartHome Hub’ Series (Models SH-100, SH-200) and the ‘SecureConnect’ Router Series (Models SC-500, SC-550).”

This example immediately clarifies which products are in scope, ties it directly to the CRA’s start date, and gives concrete examples. If you need a deeper dive into the documentation required, our guide on CRA technical documentation is a great resource.

Articulating the Security Support Period

This is the absolute heart of your policy. The CRA sets a floor with its five-year minimum, but as we’ve discussed, your product’s real-world lifespan might demand a longer commitment. Your policy must state this support period without any ambiguity for each product or product line.

Remember, the clock starts ticking the moment a product is “first placed on the market.” Be precise about this so you have a clear, auditable timeline.

Here’s a practical clause:

“Each product covered by this policy will receive security updates for a period of no less than seven (7) years from the date it is first placed on the EU market. For Product Model Z, first placed on the EU market on June 1, 2027, security updates will be provided until at least June 1, 2034. The specific End-of-Life (EOL) date for each product model will be published on our corporate website.”

This clause doesn’t just meet the CRA minimum; it extends it based on the product’s expected use, showing a real commitment to security. It also provides a specific, verifiable example and tells people exactly where to find EOL dates.

Outlining the Vulnerability Disclosure and Patching Process

Transparency in how you handle vulnerabilities is a non-negotiable part of the CRA. This section of your policy needs to lay out the journey from receiving a vulnerability report to shipping a patch. While your internal SLAs can hold the fine-grained details, the public policy should give a clear, high-level overview.

You should also point to your vulnerability disclosure programme (VDP) and the channels researchers should use. It shows you have a mature process for getting that crucial external security intelligence.

A solid vulnerability process clause should cover:

• Reporting Channels: Be specific about how security researchers can contact you. Point them to your security.txt file, a web form, or a dedicated email address. For example: “Security researchers are encouraged to report potential vulnerabilities to security@yourcompany.com. Our PGP key for encrypted communication is available on our Vulnerability Disclosure Policy page.”
• Nature of Support: Make it clear that this support is for security vulnerabilities, not for adding new features or fixing general software bugs.
• Update Delivery: Explain how users will get the updates (e.g., over-the-air, manual download) and confirm they will be provided free of charge. For example: “Updates are delivered automatically via over-the-air (OTA) updates. Users will receive a notification in the companion app to initiate the update.”

This section effectively turns your internal workflows into a public commitment, which goes a long way in building trust with customers and the security community.

Structuring Your Communication Plan

Your policy has to spell out how you’ll communicate with everyone in your supply chain—importers, distributors, and end-users. A vulnerability isn’t truly fixed until the patch is actually applied, and that requires telling people about it.

The CRA places duties on every economic operator, so your communication plan must help them meet their own obligations. An importer needs to know about a patch just as urgently as an end-user does.

A robust communication clause ensures every actor in the supply chain receives timely, actionable information. This is not just good practice; it’s a critical component of your shared responsibility under the CRA.

Here’s an example of what that commitment looks like on paper:

“Upon the release of a security update, [Your Company Name] will notify affected parties through the following channels:

• End-Users: In-app notifications and a public security advisory posted on our website.
• Distributors and Importers: Direct email notifications to registered supply chain partners within 48 hours of a patch release, including details on the vulnerability and affected product versions.

We will provide at least 180 days’ notice before a product’s declared End-of-Life date, communicated via our website and direct partner channels.”

This clause establishes a clear, multi-channel strategy. It ensures the information gets to everyone who needs it, from a homeowner with a smart device to the distributor who brought it into the country. This kind of systematic approach is the backbone of a compliant and effective CRA end of life security updates policy.

The Cyber Resilience Act doesn’t just apply to future products. It creates complex, and often misunderstood, obligations for the devices you already have on the EU market.

The transition period leading up to the full 11 December 2027 deadline requires a clear strategy for these legacy products. Ignoring them is not an option, and getting it wrong can create a major compliance and reputational risk.

While products placed on the market before that date won’t need to meet every CRA requirement retroactively, crucial provisions still apply. Key among them are the rules on vulnerability handling and incident reporting. Your CRA end of life security updates policy must therefore have a concrete plan for this transition.

Start With a Legacy Product Inventory

Your first practical step is to get a complete picture of every product with digital elements your company has placed on the EU market. This inventory is the absolute foundation of your transition strategy.

You need to map out your entire portfolio, organised by launch date. For example, imagine a manufacturer with three key product lines:

• Product Line A: Launched in 2024
• Product Line B: Launched in 2025
• Product Line C: Launched in early 2026

Each of these product families carries different obligations under the CRA’s phased timeline. A simple spreadsheet or asset management tool can get you started, but the goal is a definitive record that maps each SKU to its specific compliance path.

Understand the Critical Transitional Deadlines

The CRA’s rollout isn’t a single event. Certain rules activate much earlier than others, and they directly impact your legacy products. Two dates are especially important for your transition plan.

First, the manufacturer’s vulnerability and incident reporting duties under Article 14 kick in from 11 September 2026. For all in-scope products already on the market—including those launched in 2024, 2025, and 2026—you must have a process to report actively exploited vulnerabilities to the designated authorities.

Second, the main CRA obligations, like the five-year support window and full technical documentation, apply to products placed on the market from 11 December 2027 onwards. Products launched before this are generally exempt from these retroactive requirements, but there’s a huge catch: “substantial modifications.”

A “substantial modification” is any change made after the deadline that alters the product’s original intended purpose, function, or type in a way that could change its compliance with the CRA. This effectively turns a legacy product into a new one from a regulatory standpoint.

For instance, if your team pushes a significant firmware update in 2028 for your 2026 product line—one that adds new connectivity features or increases its cybersecurity risk—that updated version will likely need to be fully CRA-compliant. A practical example: changing a smart camera’s firmware to allow cloud storage where previously only local storage was possible would almost certainly be a substantial modification. Your transition plan must account for this.

Build Your Practical Transition Plan

With your inventory complete and deadlines understood, you can build a transition plan that prevents compliance gaps. This shouldn’t be an informal checklist; it must be a documented part of your formal CRA strategy.

The plan needs to outline precisely how you will handle products based on their market placement date.

A Real-World Example: Transition Strategy for Three Product Lines

Let’s look at how this applies to our example portfolio:

1. Product Lines A, B, and C (Launched 2024-2026):

   • Action: Implement a vulnerability monitoring and incident response workflow immediately. You must be ready to meet the 11 September 2026 reporting deadline. This means having the systems to detect, assess, and report actively exploited vulnerabilities to the designated CSIRT via ENISA’s platform.
   • Action: Define and enforce a strict policy on “substantial modifications.” Your engineering and product teams have to understand that any major post-2027 update could trigger full CRA conformity requirements, turning a simple update into a major compliance project.
   • Action: Communicate a clear support status. Even if the CRA’s five-year rule doesn’t retroactively apply, providing security updates for a defined, reasonable period builds customer trust and reduces your risk exposure.

2. New Products (Launched from 11 December 2027 onwards):

   • Action: These products must be fully compliant from day one. All your processes for secure design, vulnerability management, documentation (including the SBOM), and the five-year support window must be fully operational and evidenced.

This tiered approach ensures you allocate resources effectively. You can prioritise the urgent reporting requirements for legacy devices while systematically preparing your entire product development lifecycle for full compliance. It’s the only way to turn the complex CRA transition period into a manageable, step-by-step process.

Generating and Maintaining Your Compliance Evidence

When it comes to the Cyber Resilience Act, the guiding principle is brutally simple: if you can’t prove it, it didn’t happen. A perfectly written CRA end-of-life security updates policy is just the beginning. The real challenge is generating the complete, auditable evidence trail that regulators expect to see in your technical file, as outlined in Annex II and VII.

This isn’t about scrambling to create paperwork during an audit. It’s about building a system where compliance evidence is the natural output of your day-to-day security and development work. Market surveillance authorities will want to see a clear, traceable line from a vulnerability report all the way to a deployed patch, and your records are what will tell that story.

The Software Bill of Materials as Your Foundation

The absolute cornerstone of your evidence file is the Software Bill of Materials (SBOM). The CRA makes this mandatory, transforming the SBOM from a nice-to-have best practice into a fundamental condition for market access for any product with digital elements.

Your SBOM must be in a common, machine-readable format like SPDX or CycloneDX. While the law requires you to detail at least the top-level dependencies, both best practice and regulatory expectations are pushing for a deeper view that includes transitive dependencies. You’re on the hook for keeping this document for at least ten years after the product is placed on the market.

The SBOM isn’t a static document you create once at release. It is a living record. It must be updated with every single patch or component change, providing a real-time inventory of your product’s software DNA.

Think of it this way: when you patch a third-party library to fix a critical flaw, your SBOM must be updated to show the new, secure version. That updated SBOM becomes a key piece of evidence, proving you’ve closed the risk.

Building Your Undeniable Audit Trail

An effective audit trail isn’t just a pile of documents; it’s a coherent story that connects every piece of evidence. Regulators need to see the entire lifecycle of your vulnerability response, from the initial report to the final fix.

Here’s a practical example of how you can link records to build that undeniable proof:

1. Vulnerability Report: A researcher reports a flaw in the lib-auth-v1.2 library used in your “SmartConnect Hub” via your security@yourcompany.com inbox. You immediately log this report with a unique ID, let’s say VR-2028-005.
2. Internal Triage: Your security team confirms a CVSS score of 8.8 (High). They document this assessment in your issue tracker, making sure to link it back to the original report, VR-2028-005.
3. Patch Development: Your engineers get to work. When they commit the fix, the Git message is explicit: “Fix: Update lib-auth to v1.3 to resolve VR-2028-005.” The link is clear.
4. Firmware Release: You release a new firmware version, v2.5.1, containing the patch. The release notes specifically call out the security fix.
5. SBOM Update: The SBOM for firmware v2.5.1 is generated, and it now correctly lists lib-auth-v1.3.
6. Communication Logs: You send a notification to your distributors about the critical update and publish a security advisory on your website. These communications are time-stamped, creating a permanent record.

This chain—from email to Git commit to SBOM—creates a complete and irrefutable audit trail. It doesn’t just show you fixed the bug; it proves you followed your own documented process. For a full breakdown of what to include, you might want to look at our guide on building a CRA compliance evidence pack.

A Checklist of Essential Compliance Evidence

Whether you’re facing an importer’s verification request or a full regulatory audit, you need your technical file organised and ready. Here is a checklist of the core evidence you should be generating and maintaining as a matter of course.

• Vulnerability Management Records:
  • Logs of all inbound vulnerability reports from researchers, automated tools, and other sources.
  • Internal triage notes, including CVSS scores and your reasoning for prioritisation.
  • Records of all communications with the people who reported the vulnerabilities.
• Development and Patching Artefacts:
  • Version control history with commit messages clearly linked to specific vulnerability fixes.
  • QA reports and test results that validate the security patches.
  • Release notes that transparently identify security updates for your users.
• SBOM Lifecycle Records:
  • A complete and up-to-date SBOM for every single product version you ship.
  • A changelog or version history for your SBOMs, showing exactly how and when they have evolved.
• Supply Chain Communication Logs:
  • Copies of emails or portal notifications sent to importers and distributors about security updates.
  • Time-stamped records of any publicly posted security advisories.

By systematically collecting and organising these records, you move your policy from being a static document to a living, auditable system that truly demonstrates cyber resilience.

Digging into the details of the Cyber Resilience Act, even with a solid plan, can bring up some tricky questions. Let’s tackle some of the most common grey areas and practical scenarios we see manufacturers wrestle with when building their CRA end-of-life security updates policy.

What Does ‘Without Delay’ Really Mean in Practice?

“Without delay” is probably one of the most debated phrases in the entire CRA, and for good reason. The regulators intentionally left it open to interpretation. They’re not looking for a fixed number of days; they’re looking for a risk-based response you can defend. Everyone understands that not all vulnerabilities are equal and that a proper patch is more than a quick code change.

The real test is whether your timeline is justifiable given the circumstances. Several factors will naturally shape how fast you can—and should—roll out an update:

• Vulnerability Severity: A critical remote code execution flaw (CVSS score 9.0+) is an all-hands-on-deck emergency. A low-severity issue, on the other hand, can probably wait for the next scheduled patch release.
• Fix Complexity: Some fixes are simple. A quick configuration change can be pushed out rapidly. But a flaw buried deep in the firmware might demand serious re-engineering and testing, which just takes more time.
• Testing and QA Cycles: Rushing out a broken patch can cause more damage than the vulnerability itself. Your timeline has to bake in enough time for rigorous testing to make sure the fix is stable and doesn’t create new problems.

For example, if a critical vulnerability is found, “without delay” could mean your security team works through the weekend to develop a patch within 72 hours. This would be followed by another 48 hours of automated and manual QA before deployment. For a medium-severity bug, a 30-day sprint cycle is often a perfectly reasonable and defensible timeframe. The key is to have these SLAs defined and documented internally.

Does the Five-Year Clock Apply to Products Sold Before the Deadline?

This is a major point of confusion, so let’s clear it up. The five-year minimum support clock officially starts ticking only when a product is first “placed on the market” after the CRA’s main rules apply on 11 December 2027. A product you sell on 10 December 2027 is not retroactively covered by this five-year rule.

However, that doesn’t give pre-deadline products a free pass. There are a couple of important nuances to be aware of.

First, the reporting obligations kick in much sooner. The duty to report actively exploited vulnerabilities to the authorities applies from 11 September 2026. This affects all products on the market, including your legacy devices.

Second, think about your supply chain partners. An importer bringing your pre-2027 product into the EU will still have their own due diligence to perform. A clear EOL policy, even for older products, makes their life easier and shows you’re a reliable partner. For example, if you provide a clear 2-year support policy for a product sold in 2026, an importer can use that information to confidently handle their obligations, making them more likely to stock your product.

So, while the five-year rule isn’t retroactive, the CRA’s earlier reporting deadlines and the expectations of your supply chain mean your legacy products are very much part of the bigger picture.

How Do We Announce an End-of-Life Date Without Scaring Off Customers?

This is all about framing. A lot of manufacturers worry that advertising an EOL date sounds like planned obsolescence and will kill sales. The trick is to position your support period as a guarantee of quality and a transparent security commitment, not as a countdown to a useless product.

Don’t hide it. Make it a selling point.

Being upfront builds trust and manages customer expectations right from the beginning. It shows you’re a professional organisation that stands behind its products.

Here’s how you can phrase it positively on your website, packaging, and manuals:

• On the Box: “Includes guaranteed security updates until at least December 2032 to protect your investment.”
• On a Product Webpage: “We stand behind our products. The SmartHome Hub 2.0 comes with a 7-year security support commitment, ensuring it stays safe and reliable throughout its expected lifetime.”
• In the User Manual: “To ensure your long-term security, [Your Company Name] provides critical security patches for this product for a minimum of five years from its market launch. You can find the specific EOL support date for your model at [link to your EOL page].”

When you’re this transparent, a regulatory headache becomes a competitive advantage. It tells the world you’re serious about keeping your customers safe.

Regulus provides a step-by-step roadmap to turn complex CRA findings into an actionable compliance plan. Our platform helps you unify applicability assessments, generate tailored requirements, and structure technical evidence so you can confidently place compliant products on the European market. Gain clarity and reduce costs by visiting us at https://goregulus.com.

La entrada Your Guide to a Compliant CRA End of Life Security Updates Policy se publicó primero en Regulus.