Survivability engineering assumes systems will get compromised and looks at three things, how easily an attacker reaches a system, how much damage follows, and how long the system stays degraded. Mean time to detect, mean time to contain, and mean time to recover show that a program is putting its effort in the right places, since each one follows how quickly we notice, limit, and restore what an attacker disturbs. Mean time to protect and mean time to reproducibility are included in those numbers already, however the state of security today calls for tracking each of them separately to provide more awareness.

AI has changed the pace of attacks with attackers able to now find vulnerabilities, build exploits, and aim them at many targets in a short time, so a known vulnerability that stays open carries more risk than it used to, and a successful attack can leave a business with a large amount to rebuild all at once. That pressure usually hits two parts of the survivability model; the time a vulnerability stays reachable decides how susceptible a system is, and the time the rebuild takes decides how long recovery stays incomplete. Both are easy to overlook while they sit inside broader averages, which is why each needs its own number.

Mean time to protect (MTTP) measures when effective controls begin reducing exposure. It focuses on shrinking the opportunity to exploit, which makes it a direct measure of lowering susceptibility, the first dimension of the survivability model. The clock for a proper fix, whether a patch, a redesign, or a vendor update, runs through testing, scheduling, and approvals, and it often stretches for weeks. Attackers using AI tooling can turn a disclosure into a working exploit and point it at thousands of targets in far less time than that. MTTP covers the business during that stretch, through a virtual patch, a disabled feature, a tighter segmentation rule, a revoked credential, or a pulled integration, so protection starts while the long-term fix proceeds and patching and vulnerability operations improve. A team that tracks it can see how quickly a newly known risk stops being an easy path, which patch completion rates cannot show, since a patch metric only records the finish line.

Mean time to reproducibility (MTTRy) addresses recovery time and follows it to its end point. It measures how fast we get back to building products, systems, and the business at their best working standard, which describes recovery to 100% (or at least tries to). Restoring service is a step along the way, and a business that runs on a degraded copy, with hand-built servers, temporary exceptions, and workarounds nobody documented, has recovered its revenue while keeping its vulnerabilities. Every manual rebuild adds drift, and every untested restore carries assumptions nobody has checked. Reproducibility counters that by rebuilding from a known, hardened state, so systems return clean and the question of whether we could rebuild today gets a timed answer.

Separate numbers also expose trade-offs that a combined figure hides. A team can protect quickly and rebuild slowly, or rebuild well while taking weeks to reduce exposure, and either profile leaves the company failed for longer than its dashboards suggest. Each metric points toward a different investment, meaning, improving MTTP leads to compensating controls, standing playbooks, and the authority to block or isolate without waiting for a change window, while improving MTTRy leads to pipelines, immutable infrastructure, tested restores, and recovery paths free of circular dependencies.

The consequence map sets the targets. Systems whose loss would end the company get the shortest times on both measures, painful but recoverable systems get longer ones, and low-criticality systems get the remainder of the effort. Every figure should come from a timed exercise against a realistic attacker, since an objective nobody has measured stays a guess.

AI agents make both measures more urgent. An agent with tool access is an identity with permissions, so protecting quickly means being able to strip a tool, cut a credential, or stop a running agent within minutes of learning it can be manipulated. Reproducing quickly means storing every agent’s configuration, tool set, and instructions as code, so a compromised agent can be rebuilt clean.

Together the two metrics help cover both ends of the question survivability engineering keeps asking, which is how long we stay failed when something goes wrong. MTTP shortens the time an attacker has to get in, and MTTRy shortens the time until the business runs at its standard again. Track them separately, set them against the consequence map, and measure them often enough to see entropy moving them in the wrong direction.

MTTP tells us how quickly effective controls begin reducing exposure after a vulnerability becomes known, and MTTRy tells us how long it takes to bring products, systems, and the business back to their best working standard. The first shortens the time an attacker has to get in, the second shortens the time the business stays failed, and together they give susceptibility and recovery time numbers that leadership and engineers can both follow. Neither needs new tooling to start, since the timestamps already live in vulnerability trackers, change records, incident tickets, and the exercises we run, but the work ahead is to decide which events start and stop each clock and who records them.

The next post will cover how to begin collecting both, starting with the handful of systems at the top of the consequence map and a first set of timed exercises that produce a baseline we can push down.