Join our Newsletter — 33% off our NHI Course

MTTC

MTTC, or mean time to contain, is the average time an organization takes to stop an active security incident from spreading. In identity security, it measures how quickly teams can restrict compromised accounts, tokens, or agents, revoke access, and contain blast radius across systems, data, and operational workflows.

What MTTC Measures in Security Operations

MTTC is a containment metric, not a detection or recovery metric. It shows how long it takes the team to stop an incident from expanding, which makes it useful for comparing how well different environments can isolate compromise and limit blast radius.

Because containment is about cutting off attacker movement and access, MTTC often depends on how quickly responders can disable accounts, revoke sessions or tokens, isolate hosts, block API access, or cordon off affected automation. A shorter MTTC usually means the organisation can act decisively before the incident touches more systems or data.

Why MTTC Matters for Blast Radius

MTTC is especially important where compromise can spread through shared trust, reusable credentials, or interconnected workflows. In those environments, the first few minutes after detection often determine whether the issue stays local or becomes a broader operational event.

For identity-heavy estates, containment may need to reach beyond a single account. One compromised service principal, API key, or agent credential can create access paths into multiple applications, cloud services, or data stores, so MTTC helps measure how quickly those paths are cut off.

A useful way to read the metric is as a proxy for containment discipline: the faster the organisation can identify the scope of trust that must be removed, the less time an attacker has to move laterally, exfiltrate data, or alter records.

How to Interpret MTTC Alongside Other SOC Metrics

MTTC works best when read with detection and recovery measures, because a fast containment time can still hide slow discovery or weak restoration. A team may contain incidents quickly once alerted, yet still have a long dwell time if the initial signal arrives late.

It also helps separate incident speed into different phases. Mean time to detect asks when the problem was noticed, MTTC asks when spread stopped, and mean time to recover asks when normal operations resumed. Those are related, but they answer different operational questions.

Security Operations Metrics Guide is the right companion resource when you want to place MTTC in a broader SOC reporting model that also covers detection, response, and leadership reporting.

What Good Containment Looks Like in Practice

Good MTTC performance usually reflects more than responder effort. It also depends on whether the organisation has prebuilt containment options such as access revocation, network segmentation, token invalidation, emergency lockout procedures, and clear ownership for incident escalation.

When containment is slow, the cause is often coordination rather than awareness. Teams may know an account is compromised but still need approvals, manual changes, or cross-team handoffs before they can stop the spread. That delay is part of the metric’s practical meaning.

Strong MTTC therefore signals that the organisation can convert detection into isolation quickly and repeatably, rather than relying on improvised response during an active event.

Risk and Threat Considerations

Slow containment increases the chance that an active incident will spread before controls are applied. In identity-driven environments, that can mean more systems accessed with the same stolen account, token, key, or agent authority, and a wider blast radius before the compromise is interrupted.

Failure mechanism: The attacker keeps using valid access until responders revoke it, isolate the affected systems, or interrupt the trust path the compromise depends on.

Impact: Delayed containment can increase data exposure, service disruption, privilege escalation, and the number of systems that must be investigated or remediated after the incident.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 RS.MA-01 — Incident Mitigation MTTC measures how quickly an incident is contained once response begins.
RS.MA-02 — Incident Mitigation Containment depends on executing the right response actions to stop spread.
RC.RP-01 — Recovery Planning MTTC helps distinguish containment from later restoration and recovery work.
Recommendation — Track containment timing and reduce delays in incident mitigation actions. Predefine and practice the actions that stop incident propagation fast. Separate containment milestones from recovery milestones in incident reporting.
NIST SP 800-53 Rev 5 IR-4 — Incident Handling Incident handling includes containment, eradication, and response coordination.
AC-2 — Account Management Containment often requires disabling or constraining compromised accounts quickly.
AC-3 — Access Enforcement Containing spread depends on enforcing access limits once compromise is detected.
Recommendation — Use incident handling procedures that enable rapid containment decisions. Automate account suspension and revocation paths for compromised identities. Enforce access restrictions that can be activated immediately during incidents.
CIS Controls v8 CIS-17 — Incident Response Management MTTC is a response metric for how fast an organisation can stop an active incident.
Recommendation — Measure and improve the time needed to contain active incidents.
NIST SP 800-63 Digital Identity Guidelines Containment of compromised sessions and authenticators is directly tied to identity assurance.
Recommendation — Use identity assurance practices that support rapid session and authenticator revocation.

Practitioner Guidance

Why practitioners should care: MTTC is most useful when it is tied to a specific containment action, not just an incident closeout timestamp. If the organisation cannot say exactly when access was blocked, sessions were revoked, or segmentation was enforced, the metric will not reliably reflect true containment speed.

What to watch for: Repeated delays often point to missing playbooks, unclear decision rights, or weak pre-authorisation for emergency containment. Those gaps matter because they turn a technical response problem into an organisational coordination problem.

Practitioner takeaway: Measure MTTC in a way that captures the first effective containment action, then use that timing to identify where response authority, tooling, or access control needs to be tighter.