CRA lifecycle compliance is reshaping MedTech device trust

At a glance

What this is: This is a DigiCert analysis of how the EU Cyber Resilience Act reshapes MedTech device trust by making compliance a continuous lifecycle requirement rather than a launch milestone.

Why it matters: It matters because device trust in healthcare now hinges on managed identity, updateability, and proof of ongoing support, which directly affects how IAM, NHI, and device governance teams design controls.

By the numbers:

• The CRA introduces fines of up to €15 million or 2.5% of global annual revenue for non-compliance.
• DigiCert says its Device Trust solutions address 17 of the CRA’s 22 Annex I obligations.

Context

The central governance gap is simple: connected medical devices have often been treated as secure once they pass launch checks, even though their risk profile changes after deployment. The CRA replaces that static view with a lifecycle obligation that covers design, updateability, vulnerability handling, identity proof, and supported operation.

For identity and security teams, the important shift is that trust is no longer anchored only in device onboarding or certification. It now depends on whether the organisation can keep proving identity, integrity, and supportability after release, which brings device programmes much closer to lifecycle governance used for NHI and broader IAM controls.

In healthcare, that matters because device compromise is not just a product issue. It becomes an operational trust issue for patients, clinicians, and regulators, and the article’s position is that launch-time assurance alone is no longer an adequate control boundary.

Key questions

Q: How should MedTech teams manage device trust across the full lifecycle?

A: They should treat device trust as an operational governance process, not a launch checkpoint. That means tying identity proof, updateability, vulnerability remediation, and decommissioning to named owners and auditable records so trust can be re-established after every significant change.

Q: Why does the CRA make supported updates a security issue?

A: Because an unsupported device can remain in production even when it can no longer be trusted. If the organisation cannot patch, attest, or remediate the device reliably, then compliance and security both degrade 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: How do compliance, supportability, and accountability fit together under the CRA?

A: They become one operating model. Compliance requires evidence that the device is still supported, still identifiable, and still remediable, which means accountability has to persist through the full lifecycle rather than ending at deployment.

Technical breakdown

Why launch-time certification no longer holds up

Traditional device assurance assumes the main control point is pre-release testing and approval. The CRA challenges that assumption by requiring evidence that security persists after deployment, including update pathways, vulnerability handling, and accountability across the full support window. In practice, a device is not finished when it ships; its identity, firmware, and code-signing trust must remain verifiable as conditions change. That pushes MedTech from a one-time compliance model toward continuous evidence production.

Practical implication: treat device trust as a lifecycle governance problem, not a release gate.

How identity, integrity, and attestation work together

The article ties CRA compliance to proof of identity, integrity, and attestation, which are distinct but linked controls. Identity establishes which device is which, integrity shows that the software and firmware have not been altered unexpectedly, and attestation provides evidence that the device is running trusted code or a trusted boot state. For MedTech, these controls matter because regulators and operators need to know not just that the device was approved, but that it still matches the approved trust posture after field updates and maintenance.

Practical implication: align device identity proof with secure boot, code signing, and update validation so trust can be re-established after changes.

Why update governance becomes part of security governance

Under the CRA, software updates and vulnerability remediation are not optional operational extras. They are part of the compliance story because unsupported devices or slow patching create a trust gap even when the original build was secure. This is where lifecycle processes intersect with access governance: the organisation must know which devices are still supported, which are updateable, and which no longer deserve trust. That makes supportability an identity and governance question, not only a product maintenance task.

Practical implication: connect device support status to security policy so unsupported devices cannot remain trusted by default.

NHI Mgmt Group analysis

CRA compliance creates a lifecycle identity problem, not just a regulatory one. The article shows that MedTech trust now depends on whether a device can continuously prove who it is, what code it runs, and whether it remains supported. That moves the control boundary away from launch certification and toward lifecycle evidence, which is closer to identity governance than product compliance.

Proof of identity is now inseparable from operational trust. A device that cannot be re-identified, re-attested, or traced through its support lifecycle becomes hard to govern once it is in the field. The practical meaning is that device identity, firmware integrity, and maintenance state must be managed together, not as separate silos.

Continuous compliance is the new supportability test. The article makes clear that secure design is necessary but insufficient if updates, remediation, and documentation do not remain available after launch. That is the same lifecycle logic NHI teams already apply to credentials and workload identities, only now extended to connected medical devices.

Clear accountability matters after release, not only during design. CRA-style obligations expose a common governance weakness: ownership often fades once a device ships. MedTech programmes need durable accountability for support, attestation, and remediation across the full device lifetime, because trust breaks the moment responsibility becomes ambiguous.

Device trust now behaves like managed identity at scale. The named concept here is lifecycle trust continuity: the ability to keep demonstrating that a device remains the same governed entity from manufacture to decommission. That concept is becoming essential for practitioners who need to connect compliance evidence, support status, and identity assurance in one operating model.

What this signals

Lifecycle trust continuity: MedTech programmes now need a way to prove that a device remains the same governed asset after updates, repairs, and field maintenance. That shifts the centre of gravity from launch approvals to ongoing evidence, which is the right model for any identity programme that must survive change.

The organisations that struggle here will usually have the same blind spot: they can describe how a device was approved, but not how it stays trustworthy after it enters service. For IAM, NHI, and device teams, the planning question is no longer whether trust was established, but whether it can be sustained.

For practitioners

• Map device trust to lifecycle ownership Assign explicit owners for identity proof, software updates, vulnerability remediation, and decommissioning so responsibility does not end at launch.
• Tie attestation to field updates Require proof that secure boot, code signing, and update validation still hold after patches and remote maintenance events.
• Track supportability as a trust signal Maintain an authoritative inventory of which devices are supported, updateable, and eligible for continued trust in production.
• Build audit-ready evidence into operations Store identity, integrity, and remediation records as part of normal device operations so compliance evidence is available on demand.

Key takeaways

• The CRA turns MedTech device trust into a lifecycle governance issue, not a one-time compliance event.
• Identity proof, integrity, updateability, and supportability now have to remain demonstrable after deployment.
• Practitioners should align device ownership, attestation, and remediation records so trust can be maintained across the full device lifecycle.

Key terms

• Lifecycle Trust Continuity: The ability to keep proving that a connected device remains the same trusted, governed asset from build to decommission. In MedTech, it means identity, integrity, supportability, and updateability must remain verifiable after deployment, not only at certification time.
• Device Attestation: Device attestation is the process of checking whether a device and its software environment meet expected integrity conditions before trust is extended. For identity workflows, it should support the verification decision, not replace stronger evidence about whether the capture stream itself is authentic.
• Supportability: Supportability is the extent to which a platform can still receive guidance, updates, diagnostics, and recovery help from the vendor. In identity operations, it is a security property because unsupported systems are harder to fix quickly and can linger as unresolved exposure in critical access paths.
• Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.

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 building or maturing an IAM programme, it is worth exploring.