Notifications
Clear all
Topic starter
24/06/2026 9:22 pm
TL;DR: Exposed secrets, API keys, and certificates are a recurring incident driver, and Entro Security frames incident response around detecting, containing, eradicating, and recovering from those exposures while citing a 72% rise in data breaches from 2021 to 2023 and 35% of malware delivered by email. The real issue is that incident response plans still assume identity exposure is a rare event, not a routine operational condition.
NHIMG editorial — based on content published by Entro Security: Building a cybersecurity incident response plan, step by step
By the numbers:
- 2023 saw a 72% increase in data breaches compared to 2021.
- Around 35% of malware was delivered through email in 2023.
Questions worth separating out
Q: How should security teams respond when an NHI secret is exposed?
A: Treat the exposure as an active identity incident, not a housekeeping issue.
Q: Why do exposed API keys and tokens create such high risk?
A: Because they bypass normal authentication once discovered.
Q: What do organisations get wrong about incident response for non-human identities?
A: They often separate incident response from identity governance.
Practitioner guidance
- Map every exposed-secret response path to an owner Assign named ownership for detection, revocation, workload validation, and stakeholder notification before an incident happens.
- Build secret exposure into incident triage logic Treat leaked API keys, tokens, and certificates as active incidents even when there is no confirmed abuse.
- Pre-stage revocation and rotation runbooks Document the exact steps to revoke or rotate cloud secrets, then test them against the services that rely on those credentials.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step incident response workflow for exposed secrets, from detection through recovery
- Examples of the tools Entro says help surface exposed NHIs in cloud storage and code
- A full walkthrough of the hypothetical AWS S3 bucket exposure scenario and the response sequence
- Guidance on how to revise CSIRP documentation after a secret exposure event
👉 Read Entro Security's step-by-step guide to incident response for exposed NHIs →
Exposed NHI response gaps: what IAM teams should fix now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:33 am
Incident response for NHIs fails when teams treat secrets as static assets rather than live identities. A token, API key, or certificate is not just a configuration item. It is an active identity with its own lifecycle, blast radius, and revocation requirements. The article gets that partly right by centring containment and rotation, but the deeper lesson is that incident response and NHI governance are the same control plane when credentials can authenticate directly. Practitioners should stop separating response playbooks from identity ownership.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to Oasis Security & ESG.
A question worth separating out:
Q: Who should own secret revocation after a breach?
A: Ownership should sit with the team that can coordinate identity governance, application impact, and operational recovery. In mature programmes that usually means security and IAM together, with application owners responsible for validation. The key is pre-agreed authority, because delayed decisions are one of the main reasons secret exposure turns into extended compromise.
👉 Read our full editorial: Cybersecurity incident response for exposed NHIs needs stronger playbooks
