CRA lifecycle compliance is reshaping MedTech device trust

At a glance

What this is: This is DigiCert’s analysis of how the EU Cyber Resilience Act changes MedTech device trust from a launch-time checkbox to an ongoing lifecycle requirement.

Why it matters: It matters because device identity, update integrity, and attestation now sit alongside NHI, autonomous, and human identity controls in regulated environments.

By the numbers:

• The CRA introduces tough enforcement powers, including fines of up to €15 million or 2.5% of global annual revenue.
• DigiCert Device Trust solutions address 17 of the CRA’s 22 Annex I obligations.

👉 Read DigiCert's analysis of CRA requirements for MedTech device trust

Context

The European Union’s Cyber Resilience Act changes the compliance model for connected medical devices. Instead of treating security as a launch gate, manufacturers now have to prove secure design, updateability, vulnerability response, and device identity across the full lifecycle.

For MedTech programmes, this pushes device trust into the same governance conversation as identity lifecycle management, signing, attestation, and supportability. The practical question is no longer whether a device shipped securely, but whether it can remain trusted, supported, and auditable after deployment.

Key questions

Q: How should MedTech teams prepare for CRA lifecycle compliance?

A: They should treat device trust as an end-to-end governance problem. That means secure provisioning, signed update paths, vulnerability remediation processes, and explicit ownership through decommissioning. If those elements are not connected, the device may look compliant at launch but fail under audit or in the field.

Q: Why does the Cyber Resilience Act matter for identity and access teams?

A: Because it pushes identity evidence into the product lifecycle. Teams responsible for IAM, secrets, certificates, and attestation will need to prove who or what a device is, who can update it, and how trust is maintained after deployment.

Q: What breaks when device trust is only checked at launch?

A: Supportability breaks first, then remediation, then auditability. A device that shipped securely can still become non-compliant if update validation, ownership, or identity proof is not maintained after release. The result is a trust gap that regulators can treat as a lifecycle failure.

Q: Which frameworks are relevant to CRA-aligned device trust?

A: Zero Trust, lifecycle governance, and device identity controls are all relevant. Organisations should align device identity, attestation, and update governance to formal security frameworks, then use those controls to produce continuous evidence rather than one-time certification artifacts.

Technical breakdown

Device identity, attestation, and secure boot

CRA-aligned device trust begins before a device is activated in the field. Secure boot, cryptographic provisioning, and attestation create a chain of trust that lets manufacturers prove a device is genuine and running approved code. In practice, that chain is what makes later compliance evidence credible. Without strong identity bound to the device, update validation and support status become assertions rather than controls.

Practical implication: bind device identity to cryptographic provisioning and attestation so compliance evidence can be verified, not assumed.

Software updates and vulnerability remediation across the lifecycle

The CRA treats update capability as a security requirement, not a maintenance option. That means manufacturers need documented processes for over-the-air patching, signed software distribution, and vulnerability remediation that continue after launch. In regulated device environments, update integrity is inseparable from identity trust because the wrong updater, the wrong package, or the wrong signing state breaks assurance even if the device is still online.

Practical implication: prove who can sign, deliver, and validate updates, then connect that process to vulnerability remediation records.

Accountability from concept through decommission

Lifecycle accountability is the CRA’s deeper governance shift. Compliance evidence must survive design changes, deployment, field updates, and eventual decommissioning, which means ownership cannot disappear once the product ships. This is the same failure pattern identity teams see with unmanaged credentials: when responsibility outlives process, trust gaps accumulate. The regulated object is the device, but the governance problem is lifecycle continuity.

Practical implication: assign explicit owners for device identity, support, and decommissioning so trust obligations do not vanish after release.

NHI Mgmt Group analysis

CRA compliance is forcing MedTech teams to treat device trust as lifecycle governance, not release engineering. The article makes clear that secure design, updateability, attestation, and accountability must persist after shipment. That is the same structural shift identity teams see when governance moves from provisioning to lifecycle control. Practitioners should read the CRA as a governance reset, not a documentation exercise.

Device identity without lifecycle support creates a trust gap that looks like compliance on day one and exposure on day two. A device can be provisioned securely and still fail the CRA if update validation, vulnerability response, or accountability breaks later. That is a classic lifecycle failure mode, and it is most visible where identity proof exists without operational continuity. The implication is that device trust must be measured over time, not at certification.

Identity assurance now extends beyond humans and service accounts into regulated devices that must prove who they are and what they are running. MedTech compliance increasingly depends on the same disciplines identity programmes apply elsewhere: strong binding, controlled updates, and auditable ownership. The named concept here is compliance continuity gap: the space between launch-time approval and fielded trust where many programmes lose control. Practitioners should close that gap before regulators define it for them.

CRA pressure will accelerate convergence between product security, identity governance, and operational assurance. That matters because device trust can no longer sit in a separate engineering silo once market access depends on continuous proof. Organisations that already manage identity lifecycles will have an advantage if they apply the same discipline to connected devices. Practitioners should expect compliance evidence to become a standing operational output, not a one-time artefact.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For lifecycle governance detail, see NHI Lifecycle Management Guide for the controls that keep identity evidence current after initial provisioning.

What this signals

Compliance continuity gap: MedTech teams should expect regulators to care less about launch readiness and more about whether trust evidence survives the field lifecycle. That shift pulls device identity, update validation, and accountability into the same operating model used for managed identities elsewhere.

The operational signal is simple: if a device cannot prove its identity, support state, and update lineage on demand, the programme is already behind. Teams that already manage lifecycle controls for service accounts should extend that discipline to regulated devices and certificates now.

This is where device trust and identity governance converge. The programmes that will handle CRA pressure best are the ones that can connect provisioning, attestation, and decommissioning to a single evidence chain, rather than relying on separate engineering and compliance records.

For practitioners

• Map device trust controls to lifecycle ownership Assign accountable owners for device identity, update signing, vulnerability remediation, and decommissioning so no stage depends on informal handoffs.
• Document proof of identity and attestation Make device identity evidence, attestation records, and secure boot status retrievable on demand for audits and customer assurance reviews.
• Validate update integrity end to end Require signed packages, controlled distribution, and post-update validation so patching remains a security control rather than a delivery channel.
• Review supportability before launch decisions Treat unsupported devices, missing remediation paths, and unclear ownership as launch blockers because CRA compliance spans the full lifecycle.

Key takeaways

• The CRA changes device trust from a launch checklist into a lifecycle governance requirement.
• DigiCert says its device trust stack covers 17 of the CRA’s 22 Annex I obligations, showing how much of the compliance burden is operational rather than theoretical.
• Practitioners should tie device identity, update integrity, and ownership to the same control model they use for other critical identities.

Key terms

• Device Identity: Device identity is the cryptographic and administrative proof that a connected device is genuine and authorised to operate. In regulated environments, it links the device to trusted provisioning, update validation, and audit evidence across its lifecycle, not just at first activation.
• Attestation: Attestation is the process of proving a device or workload is in a known, trusted state. It relies on cryptographic evidence such as secure boot measurements and signing state, allowing operators and auditors to verify integrity rather than accepting the device’s claims at face value.
• Lifecycle Accountability: Lifecycle accountability is the obligation to assign clear ownership for a device or identity from design through decommissioning. It ensures security, support, and remediation decisions remain traceable after release, which is essential when compliance depends on continuous evidence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: From Launch to Lifecycle: Meeting CRA Requirements in MedTech Device Trust. Read the original.