Notifications
Clear all
Topic starter
25/06/2026 2:53 pm
TL;DR: The EU Cyber Resilience Act turns MedTech device compliance into a continuous lifecycle obligation, requiring secure design, software updates, vulnerability remediation, and proof of identity and attestation across the device lifecycle, according to DigiCert. For IAM and NHI practitioners, the important shift is that device trust now depends on managed identity and supportability, not launch-time certification alone.
NHIMG editorial — based on content published by DigiCert: From Launch to Lifecycle: Meeting CRA Requirements in MedTech Device Trust
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.
Questions worth separating out
Q: How should MedTech teams prepare for CRA lifecycle compliance?
A: They should treat device trust as an end-to-end governance problem.
Q: Why does the Cyber Resilience Act matter for identity and access teams?
A: Because it pushes identity evidence into the product lifecycle.
Q: What breaks when device trust is only checked at launch?
A: Supportability breaks first, then remediation, then auditability.
Practitioner guidance
- 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.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- How DigiCert maps its device trust capabilities to specific CRA Annex I obligations
- Product-specific detail on centralized visibility, audit-ready records, and update enforcement
- Implementation guidance for secure boot, code signing, and validation in the field
- The whitepaper summary on what manufacturers need to know to operationalise CRA requirements
👉 Read DigiCert's analysis of CRA requirements for MedTech device trust →
CRA lifecycle compliance in MedTech devices: what changes now?
Explore further
25/06/2026 4:06 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CRA lifecycle compliance is reshaping MedTech device trust
