A patch SLA measures the end of an exposure, not its size. The model those SLAs encode runs from disclosure through assessment, fix testing and deployment to closure, on the assumption that all of it completes before attackers exploit at scale [3]. Microsoft's own framing makes the arithmetic awkward: offensive timelines increasingly measured in hours against defensive processes that still take days or weeks [4], with a vulnerability announced in the morning capable of drawing active scanning by the afternoon [5]. Put one day of attacker lead time against a three-week remediation cycle and the patch closes roughly the final five percent of the exposure period, leaving about 95 percent of it to whatever else is in place [16]. Those inputs are illustrative rather than measured, but the ratio is what a security leader will be asked to account for, and Microsoft's own label for that interval is blunt: one of the most dangerous periods in modern cybersecurity [6].
The board-deck version of this quarter's answer is a faster pipeline, with mean time to remediate down and patch compliance up, and it is incomplete in a specific way. Microsoft's post concedes that awareness alone does not reduce exposure, and that many organizations know exactly which systems are vulnerable and still cannot patch them immediately [14]. The post also declines to treat the delay as sloppiness, describing dependency evaluation, fix validation and regression monitoring as necessary safeguards for business-critical environments [17]. If the delay is legitimate, the program has to own the interval rather than promise to compress it out of existence.
A skeptic has two good objections here. The first is scope: Gartner director analyst Shriya Mehrotra agrees the compression is real for high-risk internet-facing systems, where exploitation can arrive within hours while testing and deployment take weeks, but she says the dynamic does not apply equally to every vulnerability or every organization [10]. The second is provenance, since the case for moving defense into the network comes from the corporate vice president who runs Azure Networking [1]. Neither objection disposes of the operational point, because Mehrotra's own prescription is vendor-neutral: prioritize what is actively exploited and externally exposed, then use segmentation, traffic controls, WAF or IPS policy and temporary isolation until patches can be deployed safely, which she classes as an evolution of existing segmentation, compensating-control and Zero Trust practice rather than a departure [11].
The tradeoff is availability, whatever name the industry gives it. Isolating or segmenting a revenue-bearing application before a fix is validated spends the same currency an emergency patch spends, which is service continuity, only earlier and on the security team's initiative rather than the change board's calendar. Microsoft is explicit that the objective is not to avoid patching but to create a layer of defense during the period when patching has not yet completed [9], and network-level controls are attractive precisely because they operate around workloads rather than inside them, without waiting for the application to change [8]. Someone therefore needs standing authority to degrade a production path on suspicion, which makes this a governance question as much as a product one.
Whether the authority is usable depends on inventory. Mehrotra says effective real-time containment rests on accurate asset inventories, exposure mapping, traffic visibility, application context and centralized policy enforcement [12], and Bhupendra Chopra, co-founder and CRO at Kanerika, answers the readiness question with "Realistically, not yet," noting that most large enterprises lack one accurate view of their own systems because asset records sit in tools that do not talk to each other [13]. That puts the sequencing at odds with the sales cycle: the inventory and exposure-mapping work is this quarter's cost, and enforcement bought ahead of it yields policy applied confidently to the wrong assets.
