Mean time to resolution is the average time it takes a supplier to fix an issue from the moment it is reported or detected. It is a useful service metric because it shows not just whether something broke, but how quickly the vendor can restore reliable operation.
Expanded Definition
Mean time to resolution, or MTTR, is the average elapsed time between an issue being reported or detected and the point at which service is restored. In NHI and supplier security work, the metric is only useful when the starting point is unambiguous and the end state means a verified fix, not a temporary workaround.
Definitions vary across vendors and service teams, so MTTR can mean repair time, remediation time, or recovery time depending on the contract. For governance purposes, NHI Management Group recommends treating MTTR as an operational reliability measure that sits alongside incident severity, root cause closure, and recurrence prevention, rather than as a standalone score. That distinction matters when comparing a ticket that is reopened after a partial fix with one that is fully closed after credential rotation or access revocation. For a broader control context, the NIST Cybersecurity Framework 2.0 frames recovery as a core outcome, which is why MTTR becomes meaningful only when the recovery target is clearly defined.
The most common misapplication is treating MTTR as a simple vendor speed badge, which occurs when teams exclude validation, rollback, and post-fix verification from the clock.
Examples and Use Cases
Implementing MTTR rigorously often introduces measurement overhead, requiring organisations to weigh fast reporting against the cost of defining when resolution is truly complete.
- A supplier detects an expired API key, rotates the credential, confirms dependent services are healthy, and closes the incident only after validation passes.
- A platform team receives an alert for a misconfigured vault, restores secure access, and measures MTTR from alert time to confirmed remediation rather than from alert to first response.
- A third-party SaaS vendor resolves a service account lockout, but the metric excludes the time spent waiting for customer approval because the issue was not yet actionable.
- An incident caused by leaked secrets is tracked through containment, revocation, and credential reissue, with the final closure date used as the MTTR endpoint.
- For a broader NHI context, the remediation challenge is easier to understand when paired with the scale of the problem: NHI Mgmt Group notes that 91.6% of secrets remain valid five days after notification in its Ultimate Guide to NHIs, which shows why closure timing matters as much as detection timing.
In standards-based incident handling, MTTR is often paired with recovery expectations from the NIST Cybersecurity Framework 2.0, especially when evidence of recovery must be documented for audit or supplier review.
Why It Matters in NHI Security
MTTR is critical in NHI security because compromised service accounts, API keys, certificates, and automation tokens can continue to act until they are revoked, rotated, or otherwise contained. A short detection window is not enough if the fix is slow, incomplete, or lacks proof of restoration. In supplier oversight, MTTR exposes whether a vendor can actually recover from an NHI-related incident before access is abused again.
This is where governance becomes practical. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes the speed of remediation a direct risk indicator rather than a help desk statistic. If an incident is repeatedly reopened, MTTR can also reveal weak escalation paths, poor ownership, or missing automation around secret rotation and revocation. For identity operations, recovery controls should be assessed alongside the broader lifecycle expectations described in Ultimate Guide to NHIs — The NHI Market, because delayed closure often signals a deeper control gap.
Organisations typically encounter the real meaning of MTTR only after a secret leak or service-account compromise has already caused downstream disruption, at which point resolution speed becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MI | MTTR measures how quickly incidents are contained and resolved. |
| OWASP Non-Human Identity Top 10 | NHI-09 | Resolution speed reflects how fast NHI issues are remediated after detection. |
| NIST AI RMF | Risk management requires timely detection, response, and recovery metrics. |
Track containment-to-recovery duration and use it to improve incident response execution.
