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.
Editorial analysis by NHI Mgmt Group, based on content published by Oasis Security: “Cisco Breach: Non Human Identities (NHI) Compromise and Implications for DevOps Security”.
Key questions
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 exposed service account credentials create such broad risk?
A: Service account credentials often carry standing access into cloud, CI/CD, or SaaS systems, so one exposed secret can open multiple control paths at once.
Q: What are the signs that NHI governance is failing in an enterprise?
A: Common warning signs include unclear ownership for service accounts, secrets stored in code or configuration instead of managed vaults, infrequent rotation, and weak offboarding of API keys.
Practitioner guidance
- Audit public developer surfaces Review DevHub sites, documentation portals, sample repositories, and build artefacts for embedded credentials, tokens, and private keys.
- Map each secret to an owner Create a minimum ownership record for every NHI secret that includes workload, environment, and revocation authority.
- Separate convenience artefacts from live trust material Remove secrets from code, container images, and shared configuration files before those artefacts are published or reused across environments.
Bottom line: This incident shows how public-facing developer environments can become identity compromise points when live secrets are published outside governed scope.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
06/06/2026 3:16 am
Public NHI secret exposure is a governance failure, not a cleanup issue. When credentials, certificates, API tokens, and private keys are published in a public-facing environment, the organisation has already lost control of the identity boundary. The breach is created at publication time, not at the moment of attacker use. Practitioners should therefore treat secret exposure as an identity lifecycle failure that must be governed before any incident response begins.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- 61% of organisations still define privileged users as humans only, overlooking the role of non-human identities in privileged access, according to KPMG.
A question worth separating out:
Q: Should teams prioritise secret discovery or rotation first after exposure?
A: Discovery comes first because you cannot safely rotate what you cannot identify. But once the secret is mapped to its owner and use case, rotation must follow immediately. The right sequence is exposure discovery, ownership mapping, then controlled revocation or replacement.
👉 Read our full editorial: Cisco breach exposes how public NHI secrets break DevOps trust
This post was modified 5 days ago by NHI Mgmt Group