Notifications
Clear all
Topic starter
06/06/2026 1:53 am
TL;DR: Cisco confirmed that a threat actor accessed data from its public-facing DevHub after hard-coded credentials, certificates, API tokens, and private keys were exposed, according to Oasis Security. The incident shows that secrets exposure is still a DevOps trust failure, not just a cleanup problem, and that visibility, ownership, and rapid rotation now sit at the center of NHI governance.
NHIMG editorial — based on content published by Oasis Security covering the Cisco breach and exposed non-human identities: Cisco Breach: Non Human Identities (NHI) Compromise and Implications for DevOps Security
Questions worth separating out
Q: What breaks when exposed NHI secrets are left in public DevOps environments?
A: Publicly exposed NHI secrets break the assumption that internal trust boundaries still protect machine credentials.
Q: Why do service accounts and API tokens create more risk when they are long-lived?
A: Long-lived service accounts and API tokens create more risk because exposure and exploitation can happen long before defenders notice.
Q: How do security teams know if secret rotation is actually working?
A: Secret rotation is working only when teams can prove that each credential has an owner, an expiry path, and a tested revocation process.
Practitioner guidance
- Search every external-facing DevOps surface for exposed secrets Include portals, package repositories, container images, configuration files, and documentation stores.
- Map each secret to a named workload owner and runtime dependency Document which service, integration, or pipeline uses the secret, what systems it can reach, and what will fail if it is revoked.
- Shorten the usable lifetime of exposed non-human credentials Use tighter expiry, rotation triggers, and narrow scope for secrets that can reach public or semi-public environments.
What's in the full analysis
Oasis Security's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for discovering exposed secrets across DevOps repositories, images, and configuration stores
- Operational context for mapping a secret to its owner, workload, and dependent systems before rotation
- Practical remediation guidance for safe automated rotation when a credential may already be in use
- Recommendations for reducing blast radius in cloud and hybrid environments without breaking production
👉 Read Oasis Security's analysis of the Cisco NHI breach and exposed DevHub secrets →
Cisco breach and exposed NHI secrets: what IAM teams need now?
Explore further
06/06/2026 3:16 am
Exposed NHI secrets are a lifecycle failure, not just a leak. This breach worked because credentials, tokens, and keys existed in a place where they could be consumed outside their intended trust boundary. A secret that is visible to the wrong audience has already lost its governance value, even before it is used. The practitioner conclusion is that secret inventory, ownership, and offboarding are one control chain, not separate chores.
A few things that frame the scale:
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
A question worth separating out:
Q: Who is accountable when exposed machine secrets are found in a public repository or portal?
A: Accountability should sit with the team that owns the workload, repository, or portal where the secret was exposed, supported by the identity or platform team that controls rotation and access policy. NHI governance works when ownership, remediation authority, and service dependency knowledge are all clear before the next incident.
👉 Read our full editorial: Cisco breach exposes how public NHI secrets break DevOps trust
