Secrets management for compliance: where DORA, C5 and NIS2 converge

At a glance

What this is: This is a compliance-focused analysis of secrets management that shows why DORA, C5, and NIS2 all depend on stronger control of credentials, keys, and auditability.

Why it matters: It matters because IAM, PAM, and NHI teams need shared governance over secrets sprawl, rotation, logging, and incident response to meet regulatory expectations without creating fragile access models.

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.

👉 Read Akeyless's guidance on secrets management for DORA, C5 and NIS2

Context

Secrets management for compliance is the discipline of controlling credentials, API keys, encryption keys, and other secrets so regulators can see who can access what, when, and why. In practice, the problem is not just storage. It is lifecycle control across cloud, code, automation, and third-party access.

The article ties that problem to DORA, C5, and NIS2, all of which expect stronger access control, logging, recovery, and incident reporting. For identity teams, the underlying issue is that secrets sprawl creates unmanaged non-human access paths that can undermine compliance even when policy language looks complete.

Key questions

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. Assign ownership, scope every credential to a purpose, rotate it on exposure or expiry, and remove standing access wherever possible. The governance goal is to shrink the time and scope of usable access, especially in pipelines and cloud workloads.

Q: Why do secrets sprawl and duplicate credentials increase breach risk?

A: Because revoking one credential does not remove every place it was copied. If the same secret appears in repositories, pipelines, tickets, and application configs, an attacker only needs one surviving copy to regain access after the primary secret is changed.

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. A single exposed value can affect multiple workflows, tenants, or automated actions if the same credential is embedded in more than one place. The practical fix is separation of storage from usage, with tight role controls over who can read or update each layer.

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.

Technical breakdown

Why secrets sprawl becomes a compliance failure

Secrets sprawl occurs when credentials live in scripts, repositories, automation tools, and configuration files instead of a governed system. That fragmentation weakens accountability because the organisation cannot reliably prove where a secret exists, who used it, or whether it was rotated on time. For compliance regimes, the control failure is not simply exposure. It is the inability to demonstrate consistent lifecycle management across environments.

Practical implication: inventory every secret source and map it to an owner, rotation rule, and audit trail.

How rotation, JIT access, and audit logs support regulatory controls

Automated rotation reduces the lifetime of a compromised secret, while just-in-time access prevents long-lived credentials from becoming standing privileges. Audit logs add the evidence layer regulators expect for incident review, access tracing, and change accountability. Together, these controls turn secrets management from static storage into an operational control system that supports evidence production under DORA, C5, and NIS2.

Practical implication: align rotation, issuance, and logging so every privileged secret has a measurable lifecycle.

Why centralized secrets governance matters in cloud and hybrid estates

Centralization matters because cloud, on-premises, and hybrid estates often create duplicate control planes for the same identity problem. When each environment handles secrets differently, policy drift and inconsistent revocation become inevitable. A single governance model helps enforce encryption, access limits, and revocation across all systems, which is essential when regulators assess resilience rather than isolated technical controls.

Practical implication: standardize secret governance across environments instead of managing each platform as a separate exception.

Threat narrative

Attacker objective: The attacker aims to turn a single leaked secret into durable access, data exposure, or operational disruption before revocation catches up.

1. Entry occurs when secrets are exposed in scripts, code repositories, CI/CD systems, or configuration files that were never intended to hold reusable credentials.
2. Escalation follows when the exposed secret provides standing access to cloud resources, internal systems, or third-party integrations without additional verification.
3. Impact is produced when attackers use that access to move laterally, extract data, or disrupt services while the organisation is still trying to locate the secret source.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Hard-Coded Secrets in VSCode Extensions — 500+ VSCode extensions expose hardcoded tokens and credentials creating massive developer supply chain risk.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Centralization is necessary, but centralization alone does not create compliance evidence. The article’s emphasis on centralized control is directionally correct, yet regulators care about demonstrable accountability, not merely a single vault. Audit trails, access provenance, and revocation timing are the evidence layer that makes centralized control defensible. Teams should measure whether every privileged secret can be traced from issuance to retirement.

Standing secret exposure is the real control gap exposed by DORA, C5, and NIS2. These frameworks assume organisations can limit access windows, prove protection, and report incidents quickly. That assumption fails when static secrets persist for weeks or months across pipelines and third parties. Identity blast radius: the smaller the lifetime and reach of each secret, the less regulatory and operational damage a compromise can create.

NHI governance now has to sit inside compliance operations, not beside them. Secrets used by workloads, CI/CD, and integrations are non-human identities in practice, even when teams still label them as “credentials.” That means IAM, PAM, cloud security, and compliance teams need a shared operating model. The organisations that separate those responsibilities will keep discovering the same compliance failure from different angles.

From our research:

• 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.
• For lifecycle and offboarding context, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs and Guide to the Secret Sprawl Challenge.

What this signals

Secret governance is becoming a compliance signal, not just a security control. As regulators increasingly expect provable access control, logging, and recovery, teams need a secret lifecycle model that can survive audit scrutiny. With 96% of organizations having secrets scattered across environments, the gap between policy and practice is already visible.

The next maturity step is to connect secrets management to identity governance, PAM, and incident response workflows rather than leaving it as a vault administration task. That means tying revocation, rotation, and evidence capture to the same operational process. If the process cannot produce proof quickly, it is not ready for regulated environments.

Compliance-grade secrets governance: the practical test is whether a leaked credential can be found, revoked, replaced, and explained before the audit window closes. Teams that cannot answer that question need a lifecycle programme, not another storage layer.

For practitioners

• Map every secret to an owner and expiry rule Build a complete register of secrets in scripts, repositories, pipelines, vaults, and cloud services. Each entry should have an owner, purpose, rotation schedule, and revocation path so audit evidence is available when incidents or compliance reviews occur.
• 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. This reduces exposure windows and makes revocation materially faster when a secret is suspected to be compromised.
• 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. Keep the log schema consistent enough to support incident reporting under DORA and NIS2.
• Test secret revocation as an incident procedure Run exercises that start with a leaked API key or service credential and measure how long it takes to locate, revoke, replace, and validate the affected access path. Treat the result as a compliance resilience metric, not only a security drill.

Key takeaways

• Secrets management for compliance is an identity governance problem because credentials, keys, and audit trails all need lifecycle control.
• The scale problem is already visible: organisations report fragmented secrets estates, long remediation cycles, and weak dedicated platform adoption.
• The control that matters most is provable lifecycle management, because regulators need evidence of ownership, rotation, revocation, and reporting.

Key terms

• Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines — typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Just-in-time Credential Issuance: Just-in-time credential issuance creates access only when a request meets policy and then limits how long the credential remains valid. It reduces standing exposure, but it still depends on strong policy, accurate context, and reliable revocation handling.
• Audit Trail: An audit trail is a record of who accessed a system, what they did, and when they did it. For PHI environments, it provides the evidence needed to investigate incidents, support breach determinations, and demonstrate that access was attributable to a specific identity or workflow.

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

👉 The full Akeyless article covers the compliance mapping and operational controls in more detail.

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.