The vulnerability SLA clock starts in the wrong place

Federal vulnerability policy is being rewritten in triplicate this month. BOD 26-04 took effect June 10, 2026, replacing BOD 22-01 and BOD 19-02, and its first phase deadline landed the week of August 7 to 9 when every agency's vulnerability management document had to be updated to support the new tiering. Actual remediation on those tiers begins December 7, 2026. Contractors and MSSPs are inheriting the shape by procurement pressure, and every practitioner outside the federal ecosystem is reading the same directive and asking the same question.

The directive answers one half of it well. Federal teams get a four-variable risk model built on public exposure, KEV membership, exploit automatability, and technical impact, sixteen combinations, and five tier deadlines: 3 days with mandatory forensic triage, 3 days, 14 days, 60 days, and the next scheduled upgrade cycle. CISA supplies KEV, automatability, and impact via Vulnrichment; the agency supplies public exposure. CVSS is explicitly not required. The tiers bite harder than the flat clock they replaced: of the 39 CVEs CISA added to KEV between June 10 and July 29, thirty four (87%) carried a three-day-or-shorter deadline.

What the directive does not answer is when the clock starts, what stops it, what legitimately resets it, and what a re-band does to a deadline that is already running. That is the operational question every team gets wrong. The band vocabulary lives with our ACT / ATTEND / TRACK / MONITOR piece, the ticket contract with the operating model piece, and exception state with the four exceptions piece; this one owns time.

Three clocks, and programs report only the middle one

Every finding actually has three clocks running in sequence, each a wall time between a real event and a real event, not a status transition on a dashboard.

Discovery to owner runs from the scan that produced the finding to the moment a named human accepts responsibility. This is where hygiene programs lose their week, because scanners produce faster than routing accepts. A routing engine that averages six days on this clock will never make a fourteen-day tier no matter how fast infra moves.

Owner to change runs from acceptance to the moment the fix is deployed. Every dashboard shows this one because it is the one the ticketing system can compute without argument, and it is also the least honest of the three, because it hides both the routing delay in front of it and the validation delay behind it.

Change to validated runs from deployment to the moment a rescan or a validated attack-path failure proves the risk is gone. This is where paste closures rot: deployed is not fixed, and rescanned is not always fixed either.

A program that reports only the middle number tells infra the security clock is unbeatable. A finding sat in owner discovery for eight days, they had eleven days to change it, and now they are graded against the eleven. Report all three clocks and the conversation changes.

The re-banding trigger taxonomy

Banding decides which queue a finding lands in, and every band carries a deadline. What the industry has quietly built and never named is the set of events that force a mid-clock re-evaluation. Prior art: Kenna shipped Dynamic SLAs in April 2020, auto-updating the due date when the risk score crossed a band boundary (later Cisco Vulnerability Management, now end of life); SSVC (CMU SEI, v2.0, 2021) is the decision-tree ancestor; BOD 26-04 itself only re-bands implicitly, when a finding is added to KEV.

The full trigger set, each event a discrete timestamped fact with a source of record:

• KEV addition. The finding lands on the CISA Known Exploited Vulnerabilities catalog. Automatability and impact often worsen together here, because KEV addition frequently rides with a public proof of concept.
• Public exploit publication. A Metasploit module, a Nuclei template, an exploit-db entry, or a working PoC in a researcher's GitHub. Automatability is empirically higher regardless of what Vulnrichment says at the moment.
• Reachability change. A segmentation change, a new inbound rule, a new asset role, or a code path that now runs on production traffic. The finding became reachable, or the reverse.
• Internet exposure change. The affected service moved from a private VPC subnet to a public load balancer, or a management interface got mapped through an ingress by mistake.
• Ownership change. The technical owner left, the team disbanded, or the asset moved between business units. The clock keeps ticking; accountability just dropped.
• Blast radius change. The asset joined a higher trust boundary, the workload started handling regulated data, or a compromise on it now walks farther. Local technical impact moved up.

Clock arithmetic on a promotion and a demotion

The question no directive answers: an ATTEND finding on a 14-day clock, sitting at day 9, gets a KEV addition and re-bands to ACT. Does the new ACT clock start fresh at 72 hours, or does it inherit the remaining 5 days?

Our position: the new tier's clock starts fresh from the re-band event, not from the original assessment. The re-band happened because new information arrived, and the new information changes the risk model, not the calendar. Inheriting the remainder rewards a finding that was assessed slowly and punishes one that moved fast. The exception is a re-band that promotes past a committed maintenance window; there the ticket becomes an emergency and the change advisory board owes an answer in hours.

Demotion is where every program quietly cheats. An ACT finding gets a compensating control and someone drops it to ATTEND to reclaim the 14-day window. That is not a demotion; it is a paste operation that hides the risk under a new label. The rule we run: demotion requires validation evidence for the control itself, not evidence that the control exists. A WAF rule needs a BAS test that shows the exploit is blocked, a segmentation change needs a reachability rescan, and a new detection needs a purple team exercise that fires the alert on the real technique. Without the evidence, the ticket stays in its band, with a compensating control noted and the deadline unchanged.

The stop-clock rule

Deployed, rescanned, or validated: a program picks one and writes it down. We pick validated. Deployment status is a change management fact and not a security fact. Rescan closure lies whenever the scan signature does not match the failure mode, which is often. Validation is either a clean rescan tied to the actual exploit path (for hygiene findings) or a proof of failed attack (for anything KEV-listed or on the ACT queue). The clock stops the moment the evidence file exists, not the moment the change ticket resolves.

What each band should measure

Aggregate SLA compliance is a lagging vanity metric. Four numbers reported per tier actually diagnose a program:

• Time to owner. Median wall time from finding creation to named-owner assignment. Above one third of the tier deadline, routing is broken and no change velocity will save the total.
• Time to validated fix. First plus second plus third clock, measured against the tier deadline. The number a program defends in a review.
• Re-band inbound rate. Findings that entered the tier via promotion versus initial assessment. A tier where most inbound is promotion is running on stale upstream data.
• Demotion evidence rate. Percentage of demotions with a validation record for the compensating control. Anything below 100% is drift on the record.

Windows infrastructure can actually keep

The honest capacity picture is what makes flat deadlines fiction. The 2026 Verizon DBIR found only 26% of CISA KEV entries fully remediated across 13,000-plus organizations, median time to full remediation stretched from 32 to 43 days year over year, and the median KEV count an organization had to handle rose from 11 to 16. Edgescan's 2026 report puts high and critical MTTR at 54.81 days for application and API, 39 days for network and device, and 45.4% of high and critical findings still unresolved at twelve months. VulnCheck 1H 2026 reports median time from CVE publication to KEV evidence at 80 days, down from 120 in 2025, and 23.43% of KEV entries showing exploitation on or before publication day, down from 28.93% in 2025 (computed over already-confirmed-exploited vulnerabilities, not all CVEs).

Set the top tier at 3 days with forensic triage baked in and accept that not every 3-day ticket will land there. Design for what a program does when it does not: an escalation path that surfaces exactly the tickets past deadline, an exception path with an expiration, and a reporting cadence that shows the shape of the miss rather than hiding it. The band is the contract; the miss handling is the program.

Where the local model sits

CVEasy AI runs this clock arithmetic on a local-first Continuous Threat Exposure Management platform, with TRIS holding the band decision and every re-band trigger observable per asset so promotions and demotions carry evidence, not narration. The clock is a program artifact; the tooling only holds the receipts.