Mitigation

An action that reduces the impact or likelihood of exploitation without fully removing the weakness. It is useful when patching is unavailable or delayed, but it still requires follow-up because the underlying issue remains present and must stay visible to owners.

Expanded Definition

Mitigation is the deliberate use of compensating controls to reduce the impact or likelihood of exploitation when a weakness cannot be eliminated immediately. In NHI security, mitigation often protects service accounts, API keys, certificates, and automation paths while a durable fix is planned. It is not the same as remediation: remediation removes or corrects the weakness, while mitigation narrows exposure and buys time. That distinction matters because NHI risk often sits inside distributed systems where patching, secret rotation, or policy changes may require coordination across CI/CD, cloud, and application owners. For broader context on identity risk and lifecycle controls, see the Ultimate Guide to NHIs and the NIST-oriented concept of layered risk reduction in CISA cyber threat advisories. Usage in the industry is still evolving for agentic systems, where some teams call temporary guardrails a mitigation and others treat them as partial containment. The most common misapplication is treating a mitigation as a permanent fix, which occurs when owners lose track of the unresolved weakness after the initial incident is contained.

Examples and Use Cases

Implementing mitigation rigorously often introduces operational friction, requiring organisations to weigh reduced exposure against speed, automation, and developer convenience.

• Temporarily restricting an over-privileged service account to read-only access while a full entitlement review is completed.
• Replacing a hard-coded API key with network allowlisting and short-lived access tokens until the application can be refactored.
• Adding conditional policy checks and stronger logging around a sensitive agent tool while the underlying permission model is redesigned.
• Quarantining a compromised secret by revoking downstream trust paths and forcing re-authentication across dependent workloads.
• Using compensating detection controls, such as alerting on unusual token use, when Ultimate Guide to NHIs-style lifecycle fixes cannot be executed during a change freeze.

Standards bodies and incident-response guidance generally treat these steps as temporary risk reduction, not a substitute for root-cause elimination. In practice, teams often pair them with guidance from CISA cyber threat advisories to prioritise what can be contained first.

Why It Matters in NHI Security

Mitigation is central to NHI security because identity sprawl makes immediate cleanup unrealistic in many environments. NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 20% of organisations have formal processes for offboarding and revoking API keys, so exposure often persists long after a weakness is discovered. That is why mitigation must be paired with visibility, ownership, and a documented follow-up path. The Ultimate Guide to NHIs also reports that 91.6% of secrets remain valid five days after notification, which shows how often teams rely on notification without effective containment. In governance terms, mitigation prevents a known issue from becoming an active compromise while the organisation works through remediation sequencing, dependency mapping, and approval delays. It also supports Zero Trust because access is continuously narrowed rather than assumed safe. Organisational failure usually becomes visible only after a leaked secret, suspicious automation event, or privileged abuse is detected, at which point mitigation becomes operationally unavoidable to keep the incident from spreading.

Related resources from NHI Mgmt Group

• What breaks when mitigation controls are only tracked in spreadsheets?
• How should security teams implement automated third-party risk mitigation without losing governance control?
• Third-Party Risk Mitigation Automation