Topic starter
25/06/2026 1:25 am
TL;DR: Akeyless says the EU Cyber Resilience Act puts secrets management, privileged access, auditability, and lifecycle security into scope for products with digital elements, making static credentials, fragmented vaulting, and standing privilege regulatory as well as operational liabilities. The compliance boundary now extends to how access is issued, logged, rotated, and revoked across the product lifecycle.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “How to Achieve Cyber Resilience Act (CRA) Compliance with Akeyless”.
Key questions
Q: What breaks when a product still relies on standing secrets under the CRA?
A: Standing secrets create a compliance problem because they are hard to prove controlled across issuance, use, rotation, and revocation.
Q: Why does the Cyber Resilience Act make secrets management a compliance issue?
A: Because the CRA requires organisations to protect sensitive data and prevent unauthorized access throughout the product lifecycle.
Q: What are the signs that secrets governance is failing CRA expectations?
A: Frequent exceptions, fragmented vaults, hardcoded credentials, and unclear ownership are all warning signs.
Practitioner guidance
- Map CRA-controlled secrets Inventory credentials, API keys, certificates, and encryption keys used by products with digital elements, then assign each to an owner and lifecycle state.
- Replace standing privilege with JIT access Move privileged administrative and service access to task-scoped issuance with expiry and approval evidence.
- Centralise audit evidence for secrets and access Ensure access requests, authentications, rotations, and revocations are logged in one traceable path that can feed security monitoring and conformity evidence.
Bottom line: The CRA turns secrets, privileged access, and lifecycle traceability into evidence-bearing controls for products with digital elements.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- How the CRA's lifecycle requirements map to secrets management, access control, and auditability
- The specific role of certificate lifecycle management in product security compliance
- Why just-in-time access and Zero Standing Privilege reduce regulatory exposure
- How centralized governance helps multi-cloud and hybrid environments support conformity evidence
👉 Read Akeyless's analysis of CRA compliance for secrets and access control →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:50 am
CRA compliance makes secrets management a product governance control, not a back-office hygiene task. The regulation forces organisations to prove that credentials, certificates, and keys are handled securely across the full lifecycle of a product with digital elements. That changes the governance question from whether secrets exist to whether they are controlled, evidenced, and revocable. The practical implication is that secrets policy now sits alongside product assurance and compliance evidence.
A few things that frame the scale:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Who is accountable for secrets and access control under the CRA?
A: Accountability sits with manufacturers and software providers, not only operators, because the CRA places responsibility on the product side of the relationship. Security, engineering, and compliance teams must jointly evidence how secrets, privilege, logging, and update processes are controlled across the lifecycle.
👉 Read our full editorial: EU Cyber Resilience Act puts secrets and access control in scope