Mean time to resolve is only useful when policy context is defined

At a glance

What this is: This is an AppSec metric analysis showing that mean time to resolve is only meaningful when findings are measured within the right policy and scan context.

Why it matters: It matters because IAM and security governance teams often inherit metrics that look precise but fail when applied across inconsistent scopes, which can distort prioritisation for NHI, autonomous, and human identity programmes alike.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.

👉 Read Veracode's analysis of MTTR across static and SCA findings

Context

Mean time to resolve is a useful operational metric, but only when the unit of measurement matches the way findings actually behave across environments. In application security, the same flaw can appear and disappear across scans, sandboxes, and release stages, so a single average can conceal more than it reveals. That is why policy context matters more than raw speed, especially when AppSec data is being used to steer remediation across identity-linked systems and software supply chains.

For identity programmes, the lesson is broader than AppSec. Any metric that collapses different entitlements, environments, or lifecycle states into one number can create false confidence, whether the subject is service accounts, secrets, or human access reviews. The operational question is not simply how fast teams close issues, but whether the metric reflects the real control boundary that governs access and risk.

Key questions

Q: How should security teams use MTTR without distorting remediation priorities?

A: Use MTTR only within a defined policy boundary and pair it with finding severity or policy impact. The metric is most useful when it shows whether teams are resolving the issues the program actually cares about, not when it blends every scan result into one average. Separate report lines for static analysis, SCA, and roll-ups by business unit.

Q: Why does MTTR become misleading across different application scopes?

A: Because the same finding can have different meanings in different sandboxes, release stages, or business units. Averages that combine those scopes can treat unrelated remediation states as if they were equivalent, which hides where control failures actually sit. Scope definition is what makes the number governable.

Q: What do security teams get wrong about average remediation time?

A: They often assume every average is comparable. In practice, a small team with a few fast fixes can distort a program-wide number if its results are weighted equally with a much larger team. The correct roll-up uses all closed findings together, not an average of averages.

Q: When should organisations treat MTTR as a governance metric rather than a performance metric?

A: When the objective is to determine whether policy-defined findings are being fixed faster than general debt. That is a governance use case because it shows whether the policy is steering work. If the number is being used to rank teams without context, it stops being a control measure and becomes a scoreboard.

Technical breakdown

Why policy context changes mean time to resolve

Mean time to resolve is an average over closed findings, but AppSec findings are not all comparable unless they share the same policy boundary. A flaw that is closed in one sandbox may still exist in another, and a scan result can represent either a current state or a historical observation depending on how the program defines scope. Without that boundary, the metric mixes remediation, mitigation, and detection timing into one misleading figure. In practice, MTTR only becomes decision-useful when the organization defines what counts as resolved and where that definition applies.

Practical implication: calculate MTTR inside a clearly defined policy scope, not across every scan result in the programme.

How static analysis and SCA findings distort averages differently

Static analysis findings can open and close multiple times as code changes, while software composition analysis findings are tied to when a vulnerable library is first detected or reintroduced. That means the same MTTR formula behaves differently depending on the finding type. SCA also resets when a library is removed and later re-added, which prevents an artificially old age from overstating unresolved exposure. The technical point is that different detection systems generate different lifecycle shapes, so one average cannot be interpreted uniformly across them.

Practical implication: segment MTTR by finding class before using it for team targets or board reporting.

Why averages across business units can mislead

A mean across business units is not the same as the mean across all findings, because each unit contributes a different number of closed items. If a small business unit has a few fast fixes and a larger unit has many slow ones, averaging the unit averages weights them equally and distorts the result. This is a basic aggregation error, not an AppSec-specific anomaly. The correct approach is to sum all time-to-resolve values first, then divide by the total number of closed findings, so the metric reflects volume as well as speed.

Practical implication: report both per-group and rolled-up MTTR, but never mix them as if they were equivalent.

NHI Mgmt Group analysis

Policy-bound metrics are the difference between governance and theatre. Veracode’s analysis shows that MTTR only has operational value when teams agree on the policy context that defines a finding as open, closed, or mitigated. Without that boundary, the number becomes a blend of scan timing, sandbox state, and remediation status rather than a measure of control performance. For AppSec leaders, the lesson is that measurement design is part of governance, not an afterthought.

Aggregation bias is a recurring programme risk in identity and application security. When teams average business-unit metrics without weighting by finding volume, they create a result that looks mathematically clean but operationally false. This is the same class of error that appears when organisations collapse different access domains, identity types, or remediation states into one dashboard view. The practical conclusion is to preserve segmentation until the final roll-up.

Metric scope drift: a control gap where the reporting unit no longer matches the governed unit. That drift is easy to miss because the metric still produces a number, but the number may no longer describe a real operational boundary. In identity programmes, scope drift can obscure who owns a finding, which access path is in play, or whether mitigation really closed exposure. Teams should treat scope definition as a control requirement, not a reporting preference.

MTTR works best as a prioritisation signal, not a universal security score. Veracode’s own framing is strongest when MTTR is used to compare policy-impacting findings with general security debt, because that shows whether teams are fixing the issues the policy actually cares about. The practitioner mistake is to turn every average into a performance KPI. Use MTTR to steer action, but anchor it to policy relevance and finding class.

For identity-led programmes, this article reinforces a broader principle: measured speed is only meaningful when the governed object is stable. Service accounts, secrets, and access reviews all have lifecycle states that can change faster than a dashboard can flatten them. If the object being measured can move between states faster than the reporting cycle, the metric becomes descriptive but not governing. Teams should align reporting units to the real lifecycle boundary.

What this signals

Metric design will matter more as identity programmes become more distributed. As organisations spread access across SaaS, cloud, and AI-enabled workflows, the unit of governance becomes harder to pin down. That makes scope definition a first-class control, not a reporting preference, especially when teams are measuring closure speed across service accounts, tokens, and human access reviews.

Policy-impacting work is where identity governance and AppSec start to look the same. The practical signal for practitioners is that remediation reporting should distinguish between findings that affect governed access paths and findings that are simply informational. If the programme cannot separate those categories cleanly, it will struggle to prioritise the controls that matter most to the business.

Mean time to resolve becomes more useful when paired with lifecycle metrics. For identity-heavy programmes, that means looking at issuance, rotation, mitigation approval, and offboarding timings alongside closure time. The result is a more honest picture of whether the organisation is reducing exposure or merely closing tickets quickly.

For practitioners

• Define the MTTR boundary before using the metric Set the exact policy, application, sandbox, or release scope that qualifies a finding as open or closed. Do not mix remediation states from different scopes into one average, because the result will not reflect a single control boundary.
• Separate finding classes in reporting Report static analysis and software composition analysis MTTR separately, because their lifecycle logic is different. Use distinct targets for each class so teams are not compared on a metric that behaves differently by design.
• Weight roll-ups by closed finding volume When aggregating across teams or business units, sum all time-to-resolve values first and divide by the total number of closed findings. This avoids giving equal weight to tiny and large populations that should not influence the metric equally.
• Pair MTTR with policy-impacting finding rate Track whether policy-impacting findings resolve faster than general security debt. If they do not, the policy is probably not driving prioritisation and the metric is becoming a vanity measure rather than a control signal.

Key takeaways

• MTTR is only meaningful when the policy and scan scope are explicit, because averages across mismatched contexts can misstate real risk.
• Static analysis and SCA findings behave differently over time, so one organisation-wide MTTR number can hide the operational reality of remediation.
• Teams should use MTTR as a governance signal for prioritisation, then validate it with weighted roll-ups and policy-impacting finding rates.

Key terms

• Mean Time To Resolution: 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.
• Policy Context: Policy context is the control boundary used to decide whether a finding counts as open, resolved, or mitigated. It matters because the same technical issue can produce different metrics depending on which application, sandbox, release stage, or governance rule is being measured.
• Aggregation Bias: Aggregation bias happens when data from different groups is combined in a way that changes the meaning of the result. In security reporting, it often appears when teams average averages or combine findings with different lifecycle patterns, producing numbers that look precise but do not describe reality.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.

What's in the full article

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• The exact MTTR formulas used for static analysis and software composition analysis findings.
• The sandbox and policy-context rules that determine when a finding is considered resolved.
• The worked examples showing why averaging averages produces misleading business-unit comparisons.
• The distinction between resolved, mitigated, and still-open findings in Veracode Analytics.

👉 The full Veracode post includes the calculation examples and policy-context nuances behind the metric.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the control discipline needed to measure access risk with more confidence.