Loading...
New
See what manual alert triage really costs your security team.
New
See what manual alert triage really costs your security team.
See what manual alert triage really costs your security team.
See what manual alert triage really costs your security team.
Loading...
Mean time to adapt is a cybersecurity metric for the time from the first dated notice of a threat change to a defensive change proven in production. No agreed benchmark exists yet. For patching, the nearest public reference is CISA's Known Exploited Vulnerabilities (KEV) due date, whose median, by Simbian's count, fell from 21 days to 3 in 2026.
On Monday, June 8, 2026, Check Point disclosed CVE-2026-50751, a flaw that let attackers open a remote access VPN session without a valid password. CISA added it to the KEV catalog the same day and gave it a Thursday due date. Check Point traced the earliest exploitation back to May 7.
By the time defenders heard about it, attackers had been using it for 32 days, and federal agencies had three days to respond.
We counted how often CISA now does that. Of the 100 entries added to the catalog in Q3 2026, 78 got three days. In Q3 2025, 7 of 51 got three days or fewer.
Mean time to adapt asks the next question. How long would your program take to change something and prove the change worked? MTTD and MTTR can't say, because both start with an incident.
Mean time to adapt is the elapsed time between a threat change being published or reported and a defensive change running in production with evidence that it works. The term is new enough that nobody agrees where its clock starts or stops.
Pat Opet, JPMorganChase's global CISO, put it in the title of an RSAC Conference 2026 fireside. Visa's June 2026 white paper on its work in Anthropic's Project Glasswing calls it "the key operational measure of security effectiveness." In August, Cheryl Martin of C86 argued in TechRadar Pro for tracking it next to MTTD and MTTR.
| Source | Clock starts | Clock stops | Scope |
|---|---|---|---|
| Visa, June 2026 | "AI discovered weakness" | "a validated fix in production with evidence attached" | Vulnerabilities |
| Cheryl Martin, C86, August 2026 | Recognizing "a meaningful change in the threat landscape" | Turning "that knowledge into action" | Technical and organizational change |
| NIST SP 800-160 Vol. 2 Rev. 1 (2021) | "predicted changes in the technical, operational, or threat environments" | Modified "mission or business functions and/or supporting capabilities" | A resiliency goal, with no clock |
| Simbian, November 2026 | First dated notice of a threat change | The defensive change is proven in production | Detections, exposure, technology, and people |
The last row is the definition this post uses. It keeps the evidence requirement from Visa's paper but goes past vulnerabilities, since detection rules, tools, and hiring have to change too.
One warning before this reaches a dashboard: in most SOCs and incident tools, MTTA already stands for mean time to acknowledge, a clock that runs in minutes. Write the adapt version out in full.
Mean time to adapt matters now because CISA's median KEV remediation window, by Simbian's count, fell from 21 days in Q1 2026 to 3 days in Q3. Verizon's 2026 DBIR puts the median time to fully fix a known-exploited flaw at 43 days. No incident metric records either number.
Simbian's count of the KEV catalog shows 78 of 100 entries added in Q3 2026 had a due date three days or less after listing, against none in Q4 2025.
| Added in | New entries | Median window | Entries at 3 days or fewer |
|---|---|---|---|
| Q1 2025 | 73 | 21 days | 0 |
| Q2 2025 | 59 | 21 days | 0 |
| Q3 2025 | 51 | 21 days | 7 |
| Q4 2025 | 62 | 21 days | 0 |
| Q1 2026 | 71 | 21 days | 13 |
| Q2 2026 | 75 | 14 days | 32 |
| Q3 2026 | 100 | 3 days | 78 |
| October 2026 | 36 | 3 days | 29 |
The drop began before the policy. Fourteen-day due dates were already common by March, three months before Binding Operational Directive 26-04 arrived on June 10 warning that attackers' "use of AI may further narrow the time defenders have to react between patch release and possible exploitation." Stingrai reported the same shift in October.
For KEV entries added in Q3 2026, the median entry reached the catalog 8 days after its CVE record was published, and the median due date fell 15.5 days after publication. (Those are two separate medians.) In 34 of the 100, the KEV listing came within a day of the CVE record or before it.
How we counted: we downloaded the catalog on November 6, 2026 (version 2026.11.04, 1,768 entries), subtracted dateAdded from dueDate for every entry, and took publication dates from public CVE records. A dueDate is a catalog-level date. Under BOD 26-04, whose Table 1 timelines phase in within 180 days, each agency's deadline runs asset by asset from KEV listing or its own identification of the flaw, whichever comes first. The directive binds federal civilian agencies only, and a due date can't show how many of them met it. Verizon's measured figures, a 43-day median with 26% of known-exploited flaws fully fixed, cover a different population and period. Read them beside CISA's numbers and leave the subtraction alone.
Attackers are getting quicker as well. Mandiant's M-Trends 2026 estimates exploitation now comes an average of seven days before a patch.
Measure mean time to adapt per change, as the interval between two timestamped events: the first dated notice of a threat change, and the moment the defensive change runs in production with proof that it works. Then average those intervals across all changes.
Mean time to adapt = Σ (proven-in-production time − first-notice time) ÷ number of changes
Report the median and 90th percentile with it, and write both event definitions down first, or each team will invent its own.
The start is the earliest date your team could have known. For an advisory, a KEV listing, or a threat report, that's the publication time, and how long you took to read it is part of what you're measuring. Your own pentest findings start at their report date, and recurring alerts start at the first alert in the series. CVE-2026-50751 starts on June 8.
That leaves a blind spot. May 7 only surfaced a month later, so those 32 days never enter the calculation. Track attacker lead in its own column.
The stop needs evidence, such as a detection that fired on a replayed attack or an attack path a retest confirms is closed. A merged pull request with no test behind it leaves the clock running. CISA also asks for more than a patch in its most urgent cases: remediation or mitigation within three days, plus "a forensic triage of the asset to assess whether the system is compromised."
Start with a backfill. CISA publishes KEV as a JSON feed, and last quarter's list is one command away:
jq -r '.vulnerabilities[] | select(.dateAdded >= "2026-07-01" and .dateAdded < "2026-10-01") | [.dateAdded, .dueDate, .cveID, .vendorProject, .product] | @csv' known_exploited_vulnerabilities.json
From there, keep the rows that match your asset inventory and pull the ticket-open, merge, and retest dates for each. Ten entries are enough for a first median.
Every adaptation passes through four sub-clocks, and each one stalls for its own reason.
Notice: first notice to an open ticket. Intelligence that lands in an unowned inbox stalls here.
Decide: ticket to an approved plan with a named owner. Budget, change boards, and risk sign-off all sit in this one.
Change: plan to running in production. Hand-built rules, configs, and patches are the usual drag.
Prove: deployment to evidence. It gets skipped whenever nobody replays the attack.
Run CVE-2026-50751 through a hypothetical bank, using the real dates and illustrative effort. The flaw needs two changes, and they run at different speeds.
The hotfix takes the fast path. A ticket opens Tuesday, an emergency change gets approved Wednesday, the gateways are patched that night, and a retest clears on Thursday, June 11. That's three days.
The detection is slower. Someone may have got in before Monday, and the bank wants a rule for the bypass and a hunt back to May 7. The rule goes to Thursday's normal change board, one engineer spends seven days building it, and it waits seven more in the purple team's queue for a replayed attack. It's proven on June 25, 17 days after notice and 49 after the first exploitation Check Point observed.
The threat kept moving meanwhile. Check Point added new indicators of compromise on June 9, 10, and 11, which put a rule built from Monday's list out of date by Tuesday. Log a material update as a separate notice with its own clock, and leave the June 8 clock running. CISA's forensic triage guidance recommends scoping within two hours of a KEV addition, patching within 2 to 24 hours, and analysis within 24 to 48. Those timings are only recommendations, and this flaw predates the directive, but they still work as a stopwatch in a tabletop.
Track mean time to adapt separately for detections, exposure, technology, and people, since each one moves at its own speed. If you average the bank's 3-day hotfix with its 17-day detection you get 10 days, which describes neither of them.
Detections should take days. CardinalOps' 2025 report, from a company now part of Cribl, found enterprise SIEMs had detections for 22% of MITRE ATT&CK techniques in its 2025 sample, with ingested logs able to cover 90%.
Exposure has a public reference now. CISA sets a three-day due date on most new KEV entries, and the DBIR measured a 43-day median with about one KEV flaw in four fully fixed.
Technology moves with the budget. In the IANS and Artico Search report from September 2026, 45% of budgets were flat, 45% grew, and just 3% of CISOs with growing budgets named a major industry breach as a primary driver. That clock stops when the new control is running with a test behind it.
Hiring is slowest. In ISACA's 2025 survey, 38% said an entry-level hire takes three to six months and 39% said the same for other roles, and that clock runs until the new person can carry the work.
Most cyber resilience metrics, like coverage or patch compliance, report a single day, so you never see a lane speed up. Simbian's suggested starting targets, modelled on BOD 26-04's tiers: three days for the KEV flaws BOD 26-04 treats as most urgent, mainly internet-facing ones that can be automated or give total control, 14 days for other KEV flaws, and 14 days for a proven detection. They're a starting point, and no standard backs them.
Start with detections. It's the lane you can move this quarter, and its numbers make the case for engineering capacity before the next budget cycle.
Four things skew mean time to adapt: averaging rare, lopsided events; counting only the changes you made; stopping the clock at deployment; and rewarding speed with no check on what it breaks. The first three flatter the program, and the fourth can make it less safe.
Most adaptations close in days, but a few take a year, and one stalled firewall migration can drag a quarter's average further than a dozen detection fixes pull it back. Keep the average out of the board deck and show the median and 90th percentile for each lane.
An advisory that never became a ticket never enters the dataset, and a program that notices little can post a healthy number. Reconcile the feed against your tickets weekly. Anything that matches your estate with no ticket goes on an open-adaptations list at its publication age, where an advisory ignored for a month sits at the top, marked 30 days.
Marilyn Strathern's version of Goodhart's law applies here: "When a measure becomes a target, it ceases to be a good measure." Stop the clock at deployment and someone will ship an untested rule to make the quarter. The bank's rule deployed on June 18, and it would have reported 10 days for a detection nobody had seen fire.
A change board is a control, and the emergency path around it is meant for rare cases. A falling mean time to adapt can mean better engineering or fewer checks. Put rollbacks and failed changes next to it to see which.
Self-improving defense can shorten the mechanical work of changing a defense and proving the change, but it can't shorten a budget cycle, a hire, or the decision to accept a change. Every improvement still goes to your team for approval.
Simbian's AI SOC Agent investigates every alert to a verdict, so a technique that trips an alert surfaces as an investigated finding. When the same shortfall keeps recurring, Simbian writes the proposed improvement itself, attaches the evidence, and submits it for approval. It is not running a script we shipped. For detections, the AI Detection Engineering Agent builds a candidate rule from the real attack telemetry and replay-tests it against that telemetry and a baseline window, which shows that the rule matches the recorded attack and how noisy it is on normal traffic. Nothing deploys without your approval.
On a production shadow tenant streaming live Palo Alto Cortex XSIAM alerts, every XQL query failed at first, because the AI SOC Agent had never seen the language. Query success then went from 0% to roughly 70% in two iterations with zero engineers. 95% of the responses Simbian proposes are approved by the customer's own analysts. Their call, not ours. An approval rate can't show a response was right, so sample approved responses and track rollbacks here too.
Each Agent in the loop feeds the next, with pentest findings going to threat hunting, hunts going to the SOC, and whatever the SOC misses going to detection engineering. At one customer, that loop took coverage of tested MITRE ATT&CK techniques from 33% to 56% to 83% across three cycles.
Software won't shorten your budget cycle or a three-to-six-month hire, and the decide clock should stay with people. In the bank's case, where there's attack telemetry to build from, software could shorten the seven days of building and part of the seven-day wait.
Q: Who first used the term mean time to adapt? Mean time to adapt has no single known originator: JPMorganChase's global CISO, Pat Opet, gave an RSAC Conference 2026 fireside under that title, and Visa's June 2026 white paper on its Project Glasswing work formalized it for vulnerability remediation. NIST's SP 800-160 Vol. 2 had named adaptation as a cyber resiliency goal by 2019, without a time measure attached.
Q: How do you calculate mean time to adapt? For each change, subtract the first-notice time from the time the defensive change was proven in production, then average across changes. Adaptation events are rare and lopsided, so report the median and the 90th percentile per lane alongside the average. Untested changes never count as done.
Q: What is a good mean time to adapt? No published benchmark covers the whole of mean time to adapt, so Simbian suggests starting with three days for the most urgent KEV flaws, 14 days for other KEV flaws, and 14 days for a proven detection. That's a starting point, and no standard backs it. By Simbian's count, CISA's median KEV due date was 3 days from listing for Q3 2026 entries, and those due dates bind federal civilian agencies only.
Q: How does mean time to adapt differ from MTTR? Mean time to adapt measures how fast your defenses change after the threat does, whether or not you've been attacked, while MTTR, mean time to respond, measures how fast you contain one incident after it starts. A program can post an excellent MTTR and still take a year to change anything.
Q: Which cyber resilience metrics pair well with adaptation time? Pair adaptation time with MITRE ATT&CK detection coverage for the detection lane and KEV remediation time for the exposure lane. NIST defines cyber resiliency as the ability to anticipate, withstand, recover from, and adapt to attacks, and for EU financial entities, adaptation time also gives a measurable way to evidence DORA Article 13's duty to learn and evolve.
Q: Can AI help a security program adapt faster? AI can help a security program adapt faster on the mechanical work of changing a defense and proving the change, such as drafting detection changes from real attack telemetry and replaying attacks to test them. The decision to accept a change and its risk should stay with your team.
Pick the last KEV entry that touched your estate and time it from publication to proof. Then add one row under the detection and response times on your next board slide. With illustrative numbers, it might read: detection lane, median 17 days, 90th percentile 41 days; exposure lane, median 3 days, 90th percentile 9 days, oldest open item an unticketed firewall advisory at 34 days. When you'd like to see the change and prove clocks run against your own telemetry, book a demo.
