Notifications
Clear all
Topic starter
17/08/2026 4:41 pm
TL;DR: Secrets mismanagement remains a compliance problem because credentials, API keys, and encryption keys are scattered across scripts, code, and cloud systems, while frameworks such as DORA, C5, and NIS2 demand auditable control and rapid incident reporting, according to Akeyless. Long-lived secrets, weak rotation, and poor logging turn compliance into an operational identity issue, not just a policy exercise.
NHIMG editorial — based on content published by Akeyless: Introduction to Secrets Management for Compliance Regulatory Compliance
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
- 96% of organizations have secrets scattered across environments, and 70% experienced a leak in the past two years.
Questions worth separating out
Q: How should security teams govern cloud secrets across DevOps and runtime systems?
A: Treat secrets as lifecycle-managed NHI credentials, not static configuration values.
Q: Why do secrets sprawl and duplicate credentials increase breach risk?
A: Because revoking one credential does not remove every place it was copied.
Q: What breaks when secrets are reused across platform configurations?
A: When secrets are reused across platform configurations, revocation becomes hard and blast radius grows.
Practitioner guidance
- Map every secret to an owner and expiry rule Build a complete register of secrets in scripts, repositories, pipelines, vaults, and cloud services.
- Replace standing credentials with time-bound issuance Use just-in-time credential issuance for privileged workflows where possible, and remove long-lived shared secrets from automation paths.
- Standardize logging across cloud and hybrid environments Export access and change logs into a central evidence workflow so compliance teams can reconstruct who accessed a secret, when it changed, and how quickly it was revoked.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Framework-by-framework implementation detail for DORA, C5, and NIS2 compliance mapping
- Examples of how centralized secrets controls support auditing and incident reporting in practice
- Operational specifics for automated rotation, JIT issuance, and hybrid-environment governance
- Vendor-framed descriptions of how its platform is positioned for compliance workflows
👉 Read Akeyless's guidance on secrets management for DORA, C5 and NIS2 →
Secrets management for compliance - are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:46 pm
Secrets management for compliance is really lifecycle governance, not storage hygiene. The article correctly links compliance to control over credentials, rotation, logging, and revocation, but the deeper issue is identity lifecycle discipline. When secrets are scattered across code and automation, no policy statement can compensate for missing ownership and expiry. Practitioners should treat the secret as an identity with a lifecycle, not a file to store.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system, according to The 2024 State of Secrets Management Survey.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
A question worth separating out:
Q: Who is accountable when a leaked secret causes a regulatory incident?
A: Accountability should sit with the team that owns the secret lifecycle and the business system that depends on it, not with the vault alone. If the secret supports a regulated workload, the owner must be able to explain issuance, use, rotation, revocation, and reporting to auditors and regulators.
👉 Read our full editorial: Secrets management for compliance: where DORA, C5 and NIS2 converge
