Notifications
Clear all
Topic starter
25/06/2026 1:25 am
TL;DR: The EU Cyber Resilience Act makes secure-by-design controls, vulnerability handling, and auditability mandatory for products with digital elements, pushing secrets management and just-in-time access into the compliance core, according to Akeyless. The practical shift is that static credentials, fragmented vaulting, and standing privilege now create regulatory as well as operational exposure.
NHIMG editorial — based on content published by Akeyless: From Secret Management to Zero-Trust Access Control for EU Regulations
By the numbers:
- The regulation entered into force in December 2024, vulnerability reporting obligations begin in 2026, and full compliance becomes mandatory by December 2027.
Questions worth separating out
Q: What breaks when product teams keep using standing privilege under the CRA?
A: Standing privilege creates a gap between policy and evidence.
Q: When should organisations prioritise secret and certificate lifecycle controls for CRA readiness?
A: They should prioritise them early, before compliance deadlines force emergency redesign.
Q: What do security teams get wrong about just-in-time access for regulated products?
A: Teams often treat just-in-time access as a convenience layer rather than a governance model.
Practitioner guidance
- Map regulated product identities end to end Identify every human, service, and machine identity that can access product build, update, support, or telemetry functions.
- Replace standing admin paths with task-scoped access Use just-in-time access for privileged tasks and require explicit expiry after the work is complete.
- Centralise secret and certificate lifecycle controls Reduce fragmented vaulting and remove duplicated credentials across teams and environments.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- How the CRA maps to specific secrets management, encryption, and access control requirements in day-to-day operations
- Implementation detail on just-in-time access and zero standing privilege for regulated product environments
- The platform architecture behind zero-knowledge storage and distributed fragments cryptography
- Examples of how centralized governance is positioned across multi-cloud and hybrid environments
👉 Read Akeyless's analysis of CRA compliance for secrets and access control →
CRA compliance and secrets management: what IAM teams need now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 10:50 am
CRA compliance turns credential governance into product governance. The regulation does not treat secrets, certificates, and privileged access as back-office controls. It makes them part of the security case for the product itself. That means identity teams can no longer separate access design from regulatory evidence. The practical conclusion is that product lifecycle controls now need the same scrutiny as application security controls.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: Who is accountable when product identities and secrets are exposed?
A: Accountability sits with the organisation that manufactures or sells the digital product, even when tools or services are outsourced. The CRA places responsibility on the manufacturer to prove secure-by-design controls, so third-party dependency does not remove the need for identity governance, auditability, or lifecycle management.
👉 Read our full editorial: EU Cyber Resilience Act puts secrets and access control in scope
