They should treat secrets as part of the platform control plane, not as a separate vaulting concern. That means defining where secrets are created, injected, rotated, and revoked, then mapping each step to an accountable control owner. The key is to reduce the number of places where credentials can be copied or cached outside runtime identity.
Why This Matters for Security Teams
Platform teams govern secrets where developer velocity meets operational risk. In an internal developer platform, secrets are not just stored credentials; they are a control surface that determines which workloads can reach cloud APIs, data stores, signing services, and internal tools. If secrets are handled as an afterthought, teams end up with duplicated tokens, inconsistent rotation, and unclear ownership across pipelines, workloads, and human workflows.
This is why current guidance from the NIST Cybersecurity Framework 2.0 matters: asset governance and access control have to be designed into the platform, not bolted on at the vault. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secrets fragment once teams start copying them into CI/CD, ticketing, chat, and local tooling. The practical issue is not only leakage. It is also stale access, hidden inheritance, and a lack of revocation paths when workloads are decommissioned or repurposed.
In practice, many security teams encounter secret sprawl only after an exposed token has already been used to move laterally, rather than through intentional platform design.
How It Works in Practice
Secret governance in an internal developer platform should start with the lifecycle, not the storage backend. Platform teams need to define where secrets are created, how they are injected into workloads, who can request them, how often they rotate, and what automatically revokes them. That lifecycle should be tied to a named owner in the platform operating model, because a secret without an accountable owner tends to outlive the workload it supports.
Operationally, the best pattern is to prefer short-lived, runtime-issued credentials over long-lived static secrets. When a service or pipeline can obtain a token just in time, the platform reduces the number of places credentials can be copied, cached, or embedded in logs. This also shifts control from manual distribution to policy-driven issuance. For example, a deploy workflow can request a credential only for the duration of a build or release job, then lose access automatically when the job ends.
That approach aligns with the direction described in the OWASP Non-Human Identity Top 10, especially where exposed secrets, overprivileged machine identities, and weak rotation intersect. It also reflects lessons from NHIMG coverage of the Shai Hulud npm malware campaign, where secrets leaked through the software supply chain rather than through a single vault failure.
- Use a central policy layer to decide which workloads can request which secrets.
- Issue secrets through workload identity or OIDC-backed flows where possible.
- Rotate on event, not only on schedule, especially after build failures or deployment changes.
- Revoke access when a service, namespace, or pipeline is retired.
- Log secret issuance and access separately from secret values.
This guidance tends to break down in hybrid environments where legacy applications cannot consume runtime identity and still depend on copied configuration files, shared accounts, or manually managed environment variables.
Common Variations and Edge Cases
Tighter secret control often increases platform complexity, requiring organisations to balance developer convenience against stronger runtime assurance. That tradeoff is real, especially when platform teams support both modern cloud-native services and older applications that were never built for ephemeral credentials.
One common variation is when secrets are needed by build systems, not just running services. CI/CD runners often need narrow, time-bound access, but the permissions model is usually broader than it should be. Another edge case is local development: teams may permit short-lived personal access tokens for testing, but current guidance suggests these should be clearly separated from production identities and revoked quickly after use. There is no universal standard for every developer workflow, so platform teams should document exceptions explicitly rather than letting them become informal practice.
NHIMG analysis of the CI/CD pipeline exploitation case study shows why pipeline credentials deserve the same scrutiny as production service secrets. For broader context, the 52 NHI Breaches Analysis highlights a recurring pattern: once a secret is reused across environments, the blast radius grows faster than the control plane can see it.
Current best practice is evolving toward secretless or low-secret designs where possible, but that is not yet realistic for every platform. The practical goal is to minimize persistence, minimize copy points, and make revocation reliable even when the underlying application stack is imperfect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and lifecycle hygiene for machine identities. |
| NIST CSF 2.0 | PR.AC-1 | Access provisioning maps directly to controlling who can obtain secrets. |
| NIST CSF 2.0 | PR.DS-1 | Secrets are sensitive data that require managed protection across the platform. |
| CSA MAESTRO | IAM-01 | Agentic and platform workloads need governed identity and secret issuance paths. |
Protect secrets in transit and at rest, and reduce unnecessary copying into tools and logs.
Related resources from NHI Mgmt Group
- How should teams automate routine maintenance for secrets platforms without creating new operational risk?
- How should teams secure non-human identities across cloud and SaaS?
- How should teams reduce the risk from exposed NHI secrets?
- How should security teams handle leaked secrets across developer workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
