A strong signal is finding access keys embedded in source code, environment variables, old infrastructure or CI/CD pipelines with no clear owner. Another warning sign is rotation measured in months or quarters instead of runtime issuance. If the team cannot say who last used a credential and for what purpose, governance is too weak.
Why This Matters for Security Teams
When workload access is still secret-driven, the organisation is effectively trusting whoever can copy a credential rather than proving what the workload is or what it is allowed to do. That weakens SPIFFE workload identity specification-style identity models and keeps teams stuck in a secrets-first operating model. NHIMG research shows the scale of the problem: Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in code, config files, or CI/CD tools.
The practical risk is not just leakage. Secret-driven access hides ownership, blurs purpose, and makes it impossible to answer basic governance questions during an incident. It also conflicts with current guidance in the OWASP Non-Human Identity Top 10, which treats unmanaged secrets and weak lifecycle control as core NHI weaknesses. In practice, many security teams encounter this only after a pipeline compromise, expired credential, or lateral movement event has already exposed the gap.
How It Works in Practice
Teams can tell the model is still too secret-driven when access decisions depend on static material instead of runtime identity and policy. A healthier pattern is workload identity backed by cryptographic proof, short-lived credentials, and intent-aware authorisation. That means the workload authenticates as an identity, then receives just-in-time access only for the action it is trying to perform. Current guidance suggests combining this with policy-as-code so approvals are evaluated at request time rather than encoded once and forgotten.
Operationally, that looks like this:
- Workloads get a verifiable identity first, not a reusable password or API key.
- Secrets are issued with tight TTLs and revoked automatically when the task ends.
- Access is bound to context such as service, environment, workload purpose, and destination.
- Ownership is explicit, so every credential can be traced to a team and a workload.
NHIMG research on the Guide to the Secret Sprawl Challenge and the Critical Gaps in Machine Identity Management report shows why this matters: 61% of organisations still rely on spreadsheets or manual tracking for machine identities, and 57% lack a complete inventory. Those conditions make runtime governance hard because the team cannot reliably see where access exists, who owns it, or whether it still needs to exist. These controls tend to break down in legacy estate environments where batch jobs, embedded keys, and shared service accounts were designed before workload identity was available.
Common Variations and Edge Cases
Tighter secret controls often increase operational overhead, requiring organisations to balance speed of delivery against governance clarity. That tradeoff is real in hybrid estates, SaaS integrations, and older CI/CD systems where full workload identity may not be available everywhere. Best practice is evolving here: there is no universal standard for every platform, but the direction is consistent toward shorter-lived credentials, stronger ownership, and fewer standing secrets.
One common edge case is third-party tooling. If a vendor integration still depends on an API key, teams should scope it narrowly, rotate it quickly, and isolate it from human use. Another is emergency access. Break-glass secrets may still exist, but they should be rare, heavily logged, and time bound, not a normal operating model. For implementation detail, Guide to SPIFFE and SPIRE is useful for moving from long-lived secrets to workload identity, while the 52 NHI Breaches Analysis shows how poor visibility and weak lifecycle discipline repeatedly surface in real incidents. The rule of thumb is simple: if access still lives mainly in code, tickets, and memory, the environment is not yet governed by identity.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Rotation and lifecycle gaps are central to secret-driven workload access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access needs clear ownership and runtime control for workloads. |
| NIST AI RMF | GOVERN | Autonomous or dynamic workloads need explicit accountability and oversight. |
Map workload entitlements to least-privilege rules and review them on a fixed cadence.
Related resources from NHI Mgmt Group
- How can security teams tell whether OAuth access is drifting out of policy?
- How do security teams know whether vendor access is actually governed?
- How should security teams govern privileged access across service accounts and AI-driven systems?
- How can teams tell whether identity controls are keeping up with AI native change?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
