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

At a glance

What this is: This is an analysis of how secrets management supports compliance across DORA, C5 and NIS2, with the central finding that fragmented secrets handling creates both audit and resilience gaps.

Why it matters: It matters because IAM, NHI and PAM teams are being asked to prove control over secrets lifecycle, access logging and incident response, not just reduce exposure.

By the numbers:

• 96% of organizations have secrets scattered across environments, and 70% experienced a leak in the past two years.
• NIS2 requires organizations to report incidents within 24 hours and deliver a detailed report within 72 hours.

👉 Read Akeyless's analysis of secrets management for DORA, C5 and NIS2 compliance

Context

Secrets management is the discipline of storing, rotating, governing and auditing credentials, API keys and encryption keys so they are not exposed across scripts, code, cloud services and automation. In this article, Akeyless ties that discipline to compliance obligations under DORA, C5 and NIS2, where fragmented secret handling becomes a governance problem as much as a technical one.

The regulatory issue is not whether organizations have secrets, but whether they can prove who accessed them, how they were protected, and how quickly they can be revoked or reissued during an incident. That is why this topic sits at the intersection of NHI governance, operational resilience and audit readiness.

Key questions

Q: What breaks when secrets are scattered across teams, tools, and environments instead of managed consistently?

A: When secrets are scattered, organisations usually lose auditability, slow down remediation, and create inconsistent rotation and revocation practices. That fragmentation makes it harder to prove who accessed what, to contain leaked credentials quickly, and to enforce policy at scale. A consistent secrets management model supports faster response, stronger governance, and fewer hidden trust paths.

Q: Why do long-lived secrets increase enterprise risk?

A: Long-lived secrets increase risk because they remain usable long after exposure. If a key, token or certificate is stolen, the attacker can keep returning until the credential expires or is revoked. That persistence makes detection less useful unless rotation and expiration are enforced automatically.

Q: How can security teams tell whether secret management is actually working?

A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.

Q: Who is accountable when secret access is exposed across AWS, on-premises, and third-party tools?

A: Accountability should sit with the team that owns secrets governance, not with whichever system happens to store the credential. Organisations need clear ownership for lifecycle control, access policy, rotation, and audit evidence across all environments. Without that, gaps appear between cloud teams, platform teams, and security operations, and incidents become harder to trace.

Technical breakdown

How secrets sprawl breaks compliance evidence

Secrets sprawl means credentials and keys are distributed across scripts, CI/CD pipelines, application code, configuration files and cloud services without a single governance layer. That creates two technical failures at once: the organization loses inventory of where sensitive material lives, and it loses reliable evidence of who used it and when. Compliance frameworks do not just care that a secret exists. They require demonstrable control over storage, access, logging and revocation. Once secrets are copied into multiple runtime paths, auditability weakens because each copy becomes a separate risk surface. The control problem is not theoretical. A leaked secret that survives in a backup, repository or pipeline artifact can remain exploitable long after the original issue is fixed. Practical implication: centralize secret inventory and trace every credential path to a named owner and lifecycle state.

Practical implication: centralize secret inventory and trace every credential path to a named owner and lifecycle state.

Why rotation and just-in-time credentials matter

Rotation and just-in-time credentials reduce the dwell time of exposed secrets by limiting how long any credential remains valid. In practice, this changes the attack economics: a stolen secret has a shorter window of usefulness and is less likely to support long-lived access. For compliance, the value is not only reduction of risk but also proof that access is managed as a controlled lifecycle rather than a static entitlement. That matters for DORA and NIS2, which expect organizations to manage ICT risk, mitigate incidents and recover quickly. Temporary credentials also help prevent standing privilege from becoming the default operating model in cloud and hybrid environments. But rotation only helps when it is systematic. Ad hoc renewal without enforcement or telemetry still leaves the organization dependent on manual discipline. Practical implication: make secret expiry and revocation part of policy, not an optional admin task.

Practical implication: make secret expiry and revocation part of policy, not an optional admin task.

What audit logs need to prove

Compliance teams need logs that show secret creation, access, change, export, rotation and revocation in a form that can be exported for investigation and reporting. The technical requirement is not just logging volume. It is the ability to reconstruct the sequence of secret-related events fast enough to support incident reporting deadlines and internal assurance. Without that lineage, an organization cannot confidently answer basic questions such as which system used a secret, whether it was rotated after exposure, or whether a third party had access. This is especially important under NIS2, where incident reporting timelines are short and accountability is explicit. Logs that sit in separate tools without correlation do not solve the problem. Practical implication: align secrets telemetry with incident response workflows so access history can be assembled without manual forensics.

Practical implication: align secrets telemetry with incident response workflows so access history can be assembled without manual forensics.

Threat narrative

Attacker objective: The attacker objective is to turn a leaked or poorly governed secret into unauthorized access that survives long enough to affect operations, data or compliance reporting.

1. Entry occurs when a secret is exposed in a script, repository, configuration file or cloud workflow and becomes available outside the intended control boundary.
2. Credential access follows when the exposed secret is reused to authenticate to systems, APIs or cloud services without additional verification.
3. Impact occurs when the secret remains valid long enough to enable unauthorized access, service abuse or delayed detection, creating both security and reporting failures.

Breaches seen in the wild

• Toyota T-Connect key exposure 2022: A subcontractor left a T-Connect server key on public GitHub from 2017 to 2022; 296,019 customers' emails were exposed, misuse unknown.
• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets compliance is really lifecycle governance for machine credentials: DORA, C5 and NIS2 all push the same underlying issue into view, which is whether organizations can control the full lifecycle of credentials, keys and tokens. When secrets live in code, pipelines and cloud services without a governed lifecycle, compliance becomes an evidence problem rather than a policy problem. The practitioner conclusion is that secrets management must be treated as an identity control, not a storage feature.

Ephemeral access is the compliance breakpoint, not just the security optimization: Temporary credentials and automated rotation change the audit story because they reduce standing exposure and create a revocable access model. That matters in regulated environments where the organization must prove that access is limited, monitored and recoverable. The practitioner conclusion is that short-lived access should be the default control model for sensitive secrets, not an exception path.

Auditability is the control plane that separates compliant secrets handling from hidden exposure: If access to a secret cannot be reconstructed quickly, then the organization cannot reliably satisfy incident reporting, internal assurance or regulator inquiry. This is where secrets logging, exportability and event correlation become governance controls, not operational extras. The practitioner conclusion is that every secret must produce a usable evidence trail, not just an encryption state.

Standing secret exposure creates compliance debt that compounds across cloud and third-party ecosystems: The same credential can be copied into repositories, automation tooling and partner integrations, multiplying the number of places it must be discovered and revoked. That is why secrets sprawl increases both attack surface and audit surface at the same time. The practitioner conclusion is that cross-environment secret governance has to replace environment-by-environment cleanup.

Identity and resilience are converging in the secrets layer: The article is really describing a point where access control, incident response and operational continuity stop being separable concerns. A secret that can be revoked, rotated and logged consistently is doing resilience work as well as security work. The practitioner conclusion is that regulated organizations need one control model for both access assurance and recovery.

From our research library:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secret sprawl is now a governance signal, not just an operational inconvenience: When 96% of organizations have secrets scattered across environments, the practical question is whether the identity programme can still map ownership, access and revocation at scale. The control failure is not discovery alone, but the inability to maintain lifecycle evidence across code, cloud and automation.

A mature secrets programme should be judged by how quickly it can turn exposure into revocation, because slow remediation extends the useful life of a leaked credential. The reported 27-day average time to remediate a leaked secret is a reminder that incident response and secrets governance are now tightly coupled.

For practitioners

• Map every secret to an owner and lifecycle state Build a complete inventory of credentials, API keys and encryption keys across code, automation and cloud services, then assign a business owner and expiry state to each one.
• Enforce short-lived access for sensitive secrets Replace standing access with just-in-time credentials wherever possible, and make expiry, revocation and re-issuance policy-driven rather than manual.
• Instrument secret access for incident evidence Ensure logs capture create, read, update, revoke and export events for secrets, and route those events into your incident response and audit processes.
• Segment third-party secret access by purpose Treat partner and supplier credentials as temporary access paths with explicit scope, review and offboarding, so external reuse does not become hidden standing privilege.

Key takeaways

• Secrets management in regulated environments is a compliance control because it determines whether credentials, keys and tokens can be governed, audited and revoked across cloud and software systems.
• The article links secrets sprawl, audit trails and short-lived access to the practical requirements of DORA, C5 and NIS2, especially where reporting deadlines and resilience obligations are involved.
• Organizations that cannot inventory, rotate and evidence secret use quickly will struggle to prove compliance when incidents or regulator inquiries arrive.

Key terms

• 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.
• Secrets Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.
• 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 regulatory mapping and implementation detail this post intentionally leaves for the source:

• Framework-by-framework discussion of how DORA, C5 and NIS2 each connect to secrets handling
• Practical examples of centralized secrets storage, JIT credentials and automated rotation in regulated environments
• Explanation of how audit trails support the 24-hour and 72-hour reporting expectations under NIS2
• Discussion of how secrets management supports cloud, on-premises and hybrid compliance consistency

👉 Akeyless's full article covers the framework-by-framework compliance detail and operational controls.

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.