How should organisations reduce risk from exposed non-human identities and secrets?

Why This Matters for Security Teams

Exposed non-human identities and secrets rarely fail as a single event. They fail as a chain: credentials copied into tickets, chat, build logs, and config files; reused across services; then left active long after the original task ends. That is why the control objective is not just detection. It is reducing how far one leaked secret can travel and how long it can be used. Current guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both points toward ownership, lifecycle control, and least privilege as core disciplines, not optional extras.

NHIMG research shows the scale is already operational, not theoretical. In Guide to the Secret Sprawl Challenge, the evidence is clear that secrets spread beyond code into collaboration systems and pipeline artefacts, while 52 NHI Breaches Analysis shows how identity misuse often becomes a breach multiplier. In practice, many security teams encounter the exposure only after a stale token is abused, rather than through intentional secret hygiene.

How It Works in Practice

The most effective programmes treat every secret as a time-bound capability, not a permanent credential. Start by mapping where secrets are created, copied, injected, and stored. Then remove unnecessary duplication, assign a named owner to each machine identity, and shorten the lifetime of the credential to match the task. If a workload can authenticate with workload identity, prefer that over long-lived static keys. For service-to-service access, use short-lived tokens, scoped RBAC, and JIT provisioning so the secret exists only when the workload actually needs it.

This is also where monitoring alone falls short. GitGuardian reports that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which means detection without automated revocation is incomplete. That finding aligns with the broader problem described in CI/CD pipeline exploitation case study and the external evidence in Anthropic — first AI-orchestrated cyber espionage campaign report, where tool access and stolen credentials can be chained quickly once an attacker gets a foothold.

• Inventory secrets in source code, CI/CD, chat, tickets, and documentation.
• Rotate or revoke exposed credentials automatically, not manually.
• Apply scoped access and ZSP so a leaked secret cannot act as an admin key.
• Use vault controls and approval gates for new secrets sources.
• Prefer workload identity and short TTLs over reusable shared tokens.

These controls tend to break down in highly distributed build systems and agent-driven automation because secrets are copied into many ephemeral execution contexts faster than revocation workflows can catch up.

Common Variations and Edge Cases

Tighter secret governance often increases operational overhead, requiring organisations to balance agility against the friction of more frequent rotation, vault approvals, and access reviews. That tradeoff is real, especially where legacy applications, third-party integrations, or break-glass workflows still depend on static credentials. Best practice is evolving, but there is no universal standard for every environment yet.

In high-change environments, the safest pattern is usually staged modernisation: reduce the highest-value standing secrets first, then move service accounts to workload identity and JIT access where the platform supports it. For cloud-native and agentic systems, the bar is higher because autonomous software can chain tools, reuse tokens, and act outside human working patterns. The Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack both illustrate how quickly secrets exposure can propagate through trusted automation. For those environments, a secret that lives too long is often a design flaw, not just a hygiene issue.

When organisations must keep a long-lived credential, current guidance suggests compensating with stronger monitoring, narrow network reach, and explicit offboarding checks. That is especially important for identities that outlive staff, vendors, or projects.

Related resources from NHI Mgmt Group

• Why do non-human identities increase zero trust risk?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How should teams reduce the risk from exposed NHI secrets?
• How should organisations choose between RBAC and ABAC for non-human identities?