Why a Windows crypto patch was an asset inventory test

The week

On January 14, 2020, Microsoft’s monthly bundle of security fixes for Windows, released on the second Tuesday of each month in a ritual IT teams call Patch Tuesday, contained something out of the ordinary.

One of the fixes closed a flaw in the Windows CryptoAPI, catalogued as CVE-2020-0601. (A CVE number is the standard reference the security world gives each known vulnerability.) The CryptoAPI is the part of Windows that checks digital certificates. Certificates are the electronic equivalent of a notarized ID card. They let a computer confirm that a piece of software really comes from the company that claims to have made it, which is called code-signing. They also confirm that a website really is the bank or agency it says it is, using TLS, the technology behind the padlock in a web browser.

The flaw could let an attacker forge those ID cards on Windows 10 and recent Windows Server versions. Malicious software could pass as legitimate, and a fake website could pass as the real one. The weakness lay in how Windows checked certificates built on elliptic curve cryptography, a widely used family of encryption methods. Researchers gave it nicknames such as CurveBall. Within days of the patch, several independent researchers published proof-of-concept code showing that forged certificates really did work against unpatched machines.

The same bundle also fixed serious flaws in Remote Desktop Gateway, a service that lets people connect to office computers from outside. Two of those flaws, CVE-2020-0609 and CVE-2020-0610, could let an attacker run code on the gateway without logging in. A third, CVE-2020-0611, affected the Remote Desktop client. The gateway flaws drew less attention than the NSA’s role, but they were the ones an attacker could reach directly from the internet.

Unusually, the National Security Agency publicly confirmed that it had found the CryptoAPI flaw and reported it to Microsoft. Intelligence agencies rarely put their names to such discoveries. Anne Neuberger, who led the agency’s recently created Cybersecurity Directorate, announced it on a call with reporters. The NSA also published an advisory with detection advice. Microsoft and the NSA both said they had seen no exploitation of the flaw before the patch.

The patch carried a detail that defenders noticed. Patched systems would write an entry to the Windows event log when they saw a certificate that appeared to exploit the flaw. Security teams could therefore look for attempted attacks as well as close the hole.

The same day, the Cybersecurity and Infrastructure Security Agency, CISA, the federal agency responsible for protecting civilian government networks, issued Emergency Directive 20-02. An emergency directive is a binding order to federal civilian agencies. CISA’s first, a year earlier, had dealt with tampering of agency domain name records. This one required agencies to apply all of the January updates to affected endpoints (laptops, desktops and servers) by 5 p.m. on January 29, ten business days away.

The directive had several further parts. Agencies had to file an initial status report by January 17, using a CISA template that asked for constraints and projected completion dates. By January 29 they had to block newly provisioned or long-disconnected machines from their networks until those machines were patched. Department-level chief information officers had to attest that the work was done. CISA advised agencies to start with mission-critical systems, High Value Assets, internet-facing systems and servers. Any endpoint that could not be patched in time should be removed from the network.

CISA also set out its own follow-up. From February 3, its director would engage the CIOs of agencies that had not finished. By February 14, CISA would send a cross-agency status report to the Secretary of Homeland Security and the Director of the Office of Management and Budget.

January 14 was also the day extended support ended for Windows 7 and Windows Server 2008. The January bundle was the last free security update those systems would receive. From then on, organizations still running them would receive no routine security fixes unless they paid Microsoft for extended updates. Microsoft had published that date years in advance, and mainstream support for Windows 7 had ended in January 2015. The deadline was no surprise. What made it awkward was the coincidence. On one day, agencies faced both an urgent deadline to fix their newer systems and a growing population of older ones that would no longer be fixed at all.

Emergency Directive 20-02 read like a patching instruction: install this update, on these machines, by this date. In practice it tested four capabilities that agencies often treat as one. They are knowing what you have and who owns it, moving fast without breaking mission systems, handling systems that cannot be patched at all, and proving the result to someone outside the agency.

Installing the update was rarely what held anyone up. Microsoft had done the hard engineering. The other four capabilities were what separated agencies that finished comfortably from those that scrambled. They are also exactly the capabilities that any large organization, public or private, needs on the day a serious flaw is announced in software it depends on.

The sections below begin with the flaw itself and how an emergency patch unfolds inside a real organization. They then take the four capabilities in order, look at where the cost lands, and close with what readiness looks like and the questions a CIO should be able to answer.

A flaw in the machinery of trust

The flaw sat in an unglamorous but fundamental part of the system, and the stakes follow from that.

Why certificates matter

Much of the trust on which modern computing depends rests on digital certificates. When an employee’s laptop installs an update, it checks a certificate to confirm that the update genuinely comes from the vendor. When a citizen visits a benefits portal, their browser checks a certificate to confirm that the site really belongs to the agency. These checks happen silently, thousands of times a day, and nobody notices them until they fail.

A flaw in the checker itself is therefore serious in a particular way. It does not break into one system; it undermines the method every system uses to tell genuine from fake.

How the forgery worked

A certificate carries a public key, and the computer checks that the key traces back to a root authority it already trusts. Elliptic curve keys are defined against a set of mathematical rules, called curve parameters. Most certificates use a few standard curves, named rather than spelled out. The standard also allows a certificate to spell out its own parameters.

Windows compared the public key in a certificate with the key of a trusted root, but did not check that the curve parameters were the standard ones. An attacker could therefore write custom parameters into a certificate, chosen so that a key they controlled appeared to match a trusted root. Windows would then accept certificates signed by the attacker as if a trusted authority had issued them.

The fix made Windows check the parameters as well as the key. That is a small change in code and a large one in consequence, because it touched every program on the machine that relied on Windows to judge a certificate.

Two flaws, two kinds of urgency

The Remote Desktop Gateway flaws were urgent in a different way. A gateway faces the internet by design, so anyone can try to reach it. A flaw that runs code without a login is the kind attackers automate and spray across the internet. The certificate flaw, by contrast, mattered most where attackers could put a forged certificate in front of a user or a system, for example through a fake website or a malicious download.

A sound response ranked the two accordingly. Internet-facing gateways went first, then servers and the bulk of desktops. The directive’s own priority order made the same point.

What a patch is, and why it is not the whole job

A patch is a software update that fixes a specific flaw. Applying one is usually a matter of pushing it out through management tools and restarting the machine. The hard part is everything around that. Someone has to find every machine that needs it and decide which ones can be restarted safely, and when. Someone has to deal with machines that cannot take it, and confirm afterward that the fix actually landed.

End of support

Software vendors support each version of their products for a set period. When that period ends, they stop shipping security fixes. A system running unsupported software does not stop working, which is why so many remain in use. But each newly discovered flaw in it stays open for good. Windows 7 and Windows 8.1 used older certificate code and were not affected by the CryptoAPI flaw. The urgent fix was for the newer systems, which made the older ones easy to forget in the rush. On January 14, 2020, Windows 7 and Windows Server 2008 crossed that line, unless their owners paid for extended updates.

How an emergency patch actually unfolds

Take a mid-sized federal bureau and follow the ten business days. On the Tuesday, the directive arrives in the afternoon. The security team reads it, confirms which Windows versions are affected and asks the infrastructure team for a list of every machine running them. The infrastructure team pulls a report from its management tools, which covers most desktops and the servers it runs directly.

On the Wednesday and Thursday, the gaps appear. The report does not include servers that a program office bought for a grant-funded project, or machines at a contractor’s site that process the bureau’s data. Emails go out asking who owns them. Meanwhile, the bulk of desktops are patched overnight, and the first status report goes to CISA with a number that everyone suspects is incomplete.

The directive’s priority order shapes those first days. Internet-facing systems and the agency’s High Value Assets, the systems it has formally designated as most important to its mission, go to the front of the queue. Servers follow. That sounds simple until the team discovers that the list of High Value Assets is maintained by a different office, in a different format, and does not map cleanly to server names.

What the security team does alongside

While infrastructure staff push the update, the security team has its own list. It checks which systems validate certificates on behalf of others, such as web proxies that inspect encrypted traffic. If a proxy judges certificates for thousands of users, patching their laptops does not protect them until the proxy is fixed too. It starts collecting the new event log entries centrally. It also checks whether the Remote Desktop Gateways are reachable from the internet, and whether they can be restricted while they wait for the update.

In the second week, the work slows down to the pace of the hardest systems. A case management application depends on an older component, and its owners want to test before rebooting. A set of laboratory machines turns out to run Windows 7, so the patch does not apply at all and a different conversation begins. Field staff laptops that have not connected for weeks cannot be reached. By the deadline, most systems are fixed, a short list carries documented exceptions, and the CIO signs an attestation based on reports compiled by hand.

Contractor-operated systems add their own friction. Federal security law covers systems a contractor runs on an agency’s behalf, so they fall within the directive. But the agency cannot patch them directly. It must ask the contractor, wait for the contractor’s change process, and then rely on the contractor’s evidence. Where the contract says nothing about emergency patching timelines, every request is a negotiation.

Nothing in that story is a failure of technical skill. Each delay comes from a missing piece of organizational preparation: an incomplete list, an unknown owner, an unagreed rule, a budget decision deferred. For that reason the four capabilities below matter more than the patch itself.

Knowing what you have and who owns it

The flaw affected specific Windows versions. That sounds precise until an agency has to produce a list. Endpoints managed by central IT are usually well inventoried. Servers run by program offices, laboratory systems, systems operated by contractors on the agency’s behalf, and cloud instances created outside standard pipelines often are not. An emergency directive exposes that gap immediately, because the clock starts before the inventory is reconciled.

Agencies that had invested in the asset management capabilities of the Continuous Diagnostics and Mitigation program had a head start, but only where the tooling covered the whole estate. (Continuous Diagnostics and Mitigation is a federal program that provides agencies with tools to discover and monitor the devices on their networks.) Coverage, not tool choice, decided who could answer quickly.

A useful metric is the share of systems discovered on the network that also appear in the authoritative inventory, the official list of what the agency owns. Where that share is low, every directive starts with a hunt. Say a state revenue department’s central IT team manages several thousand desktops and is confident about them. But a network scan also finds a few dozen servers in the audit division and a set of machines in a contractor-run call center. It also finds several virtual servers an analytics team set up in the cloud last year. None appears in the official inventory. Each one is a question that must be answered before the deadline, and each answer takes days of emails.

Ownership is the second half of inventory. Knowing that a vulnerable server exists does little if nobody can say who may reboot it. An inventory that records a technical owner and a business owner for each system turns a list into something an incident team can act on. Agencies without owner data spent the first days of the directive finding people rather than fixing systems.

Owners who can say yes

An owner field is only useful if the named person can make a decision at short notice. A business owner who must consult a committee before approving a restart is a bottleneck with a name attached. The better pattern is to record, for each critical system, who may approve an emergency restart, who is the deputy, and what notice the mission needs. That record should be checked when people change roles, not discovered to be stale during the next directive.

Three lists that never quite agree

Most organizations hold at least three lists of their devices. The management tool lists what it manages, which excludes anything without its agent installed. The network scanner lists what answers on the network, which excludes laptops that are off or away. Procurement and finance records list what was bought, which excludes what was donated, transferred or created in the cloud.

The practical work of inventory is reconciling those three. Each device that appears on one list but not another goes into a short queue, and someone decides whether it is a stale record, a missing agent or an unknown system. Teams that reconcile weekly keep the queue short. Teams that reconcile only during an emergency face hundreds of mismatches at once.

How the problem differs by type of organization

The same gap looks different across sectors. A federal agency has CDM tooling and a reporting line to CISA, but often a sprawl of program offices and contractors. A county government may have a small central IT team, a sheriff’s office with its own systems, and a managed service provider whose records live outside the county’s tools.

A community bank usually has a tighter estate, but much of it runs at the core banking processor and other service providers, so its inventory must include what those providers run for it. A health system carries the hardest version. Imaging systems, lab analyzers and other clinical equipment often run Windows inside, and the hospital may not be allowed to patch them without the manufacturer’s approval. Each of these organizations needs the same list, built from different sources.

Moving fast without breaking mission systems

A fix to a cryptographic library touches certificate validation everywhere. Most systems take such updates without incident. Mission applications with old dependencies, specialized devices and tightly controlled production systems need testing first. The tension between speed and stability is real, and it is usually resolved badly when it is resolved for the first time under deadline.

Agencies that coped well had pre-agreed rules.

• Standard workstations are patched immediately.
• Defined classes of server get a short test window, measured in days.
• A named official can grant an exception for a fixed period, with a compensating control such as network isolation recorded alongside it.

Those rules are cheap to write in a calm month. Ten business days leaves no time to negotiate them.

Exceptions that expire

Every emergency produces exceptions, and the risk lies in what happens to them afterward. A sound exception record names the system, the reason it cannot be patched, the compensating control, the official who approved it and the date it lapses. When the date arrives, the exception either closes or goes back to a more senior official for renewal. Exceptions without expiry dates turn into permanent architecture. An agency that reviews its open exceptions monthly will usually find several whose reason has since disappeared.

Testing a change to certificate checking

Because the fix changed how Windows judged certificates, the useful tests were the ones that exercise certificates. For a federal agency, smart-card sign-in with PIV cards, the identity cards federal employees use to log on, is the obvious example. Others include connections to internal websites, VPN sign-in, code-signing checks in software deployment, and any application that talks to another over encrypted links.

A test plan of that kind fits on a page and can be run in an afternoon by people who know the systems. Written in advance, it turns the speed-versus-stability argument from a debate into a checklist. Written during the emergency, it takes days.

Rings rather than a single push

Many organizations deploy updates in rings. A small pilot group gets the update first, then a larger early group, then everyone else. In a normal month, the rings may be spread over weeks. In an emergency, the same structure can run in days, with each ring lasting long enough to catch obvious breakage. The rings already exist, so nobody has to invent a process under pressure.

Users experience an emergency patch mostly as a restart prompt, and many will postpone it as long as they can. A short note from the CIO explaining why this restart matters reduces that delay. So does a firm rule that the machine restarts on its own after a stated grace period. Both should be agreed before the emergency, because changing restart behavior mid-week generates calls to the help desk at exactly the wrong time.

Change boards are a frequent bottleneck. A change board is the committee that reviews and approves alterations to important systems, to avoid one fix causing another outage. A process built for monthly review cannot approve hundreds of emergency changes in a week. An expedited path, with authority delegated in advance for directive-driven changes, removes the bottleneck without removing the record.

Verification closes the loop. A deployment tool that reports success does not prove the system is protected, because some updates require a restart and some devices are offline when the update is pushed. Agencies that checked the actual file version or build number on each endpoint, rather than trusting deployment status, found gaps that would otherwise have surfaced only in an audit. Checking for attempted attacks belonged in the same step. Because the patch logged suspicious certificates, teams that collected those logs centrally could see whether anyone had tried the forgery against them. Laptops that rarely connect to the agency network are a common blind spot, and the directive’s requirement for controls that patch new or long-disconnected devices before they connect addressed exactly that.

Systems that cannot be patched at all

The same day, Windows 7 and Windows Server 2008 left extended support for most customers. Some agencies bought paid extended security updates. Others still had machines embedded in equipment, kiosks or legacy applications that no update would reach. Examples include a laboratory instrument whose controlling computer was certified with a particular version of Windows, or a public kiosk built years ago by a contractor who no longer exists. Those systems never appear in a patching report, because there is nothing to apply.

They need a different treatment: isolation from general networks, compensating controls, a funded replacement plan and an accountable executive who signs the risk acceptance. This category grows unnoticed, because replacement is a capital decision and patching is an operational one, and the two sit in different budgets. The person who feels the risk is rarely the person who controls the money to remove it.

Isolation deserves a word of explanation, because it is the main tool for living safely with such systems in the meantime. It means placing the unsupported machine on its own section of the network, with tight rules about what it can talk to and what can talk to it. A laboratory instrument may need to send results to one database and nothing else. Suppose it cannot browse the internet, open email or reach the rest of the office network. Then a flaw in its software is much harder for an attacker to reach and much less useful if they do. Isolation is not a permanent answer, since rules drift and exceptions accumulate, but it turns an open risk into a contained one while the replacement is funded.

Who signs the acceptance

In federal agencies, the official who grants a system its authority to operate is also the person who accepts its residual risk. That official, the authorizing official, is the right signatory for an unsupported system. The signature should name the compensating controls, the replacement date and the funding source, and it should expire. When the authorizing official works in a program office and the security team works elsewhere, the signature also forces the two to agree on the facts.

Outside government, the equivalent is a named executive in the business line that depends on the system. A bank might route the acceptance through its operational risk function. A hospital might route it through the committee that oversees clinical technology. What matters is that the person who signs controls the budget that could remove the risk.

Devices someone else controls

The hardest unpatchable systems belong in a category of their own: devices whose software the organization does not control. Medical equipment is the clearest case, because a manufacturer may need to validate an update before a hospital can install it. Kiosks, some building systems and self-service machines often run embedded versions of Windows with their own support timelines, which differ from the desktop versions.

For such devices, the useful questions go to the vendor. Organizations need to know when a validated update will be available, and what the vendor recommends in the meantime. The answer, and the date it was given, belong in the risk record. Procurement can help by asking for a documented patching commitment and a published end-of-support date before the next device is bought.

Paid extended updates buy time only if the time is used. Each year of extended support should be treated as a deadline for replacement rather than a renewal option. An organization that renews extended support three years running without a replacement project has paid three times and is no closer to retiring the systems.

The pricing made the point for anyone who looked. Extended updates for Windows 7 were sold for up to three years, and the price rose each year. That design is a nudge rather than a business model. It rewards organizations that use the first year to plan replacement, and penalizes those that treat it as a standing arrangement.

Proving it to someone outside the agency

The directive required agencies to report status to CISA. Reporting turns an internal task into an external accountability, and it changes behavior. The requirement for the CIO to attest personally had the same effect, because a senior official’s name was now attached to the claim. It also showed how many agencies relied on spreadsheets assembled by hand from several tools, with the burden falling on the same staff doing the patching.

Manual reporting has a second cost. Numbers assembled under pressure are often wrong in both directions, overstating progress where a tool counted a patch as applied before a reboot, and understating it where systems were missing from the inventory. A CIO who attests on the basis of such numbers is taking a personal risk without knowing it.

The durable investment is automated, continuous reporting of patch and configuration state, drawn from the same data used to manage systems. When the next directive arrives, the answer should come from a query rather than a data call. It also spares the people who fix systems from compiling spreadsheets for each data call.

What an attestation should rest on

A defensible attestation rests on three pieces of evidence. The first is per-device patch state, read from the device rather than from the deployment tool. The second is a list of exceptions, each with its owner, approver, compensating control and expiry date. The third is a statement of the denominator: how the agency knows its inventory is complete, and what share of discovered devices it could not account for.

The third piece is the one most often missing. A report that says every known endpoint is patched means little if nobody knows how many endpoints are unknown. Stating that gap openly is more credible to an oversight body than a figure of one hundred percent.

Attestation also creates an incentive worth watching. When a senior official’s name rests on a completion figure, there is pressure to narrow the scope until the figure is true. Systems get reclassified as out of scope, or left off the list without comment. Oversight bodies can counter that by asking how the scope was set, and leaders can counter it by rewarding accurate reports of gaps rather than clean ones.

The same proof, asked by other people

Outside the federal government, the request comes from different directions. Bank examiners ask how a bank tracks and remediates vulnerabilities, and firms that handle card data must meet the payment card industry’s standard, which sets a deadline for installing critical security patches. Hospitals answer to HIPAA, whose Security Rule requires a risk analysis but has not, so far, set fixed patching deadlines. Changes proposed in January 2025 would make asset inventories explicit. State and local agencies hear the question from state auditors and from cyber insurers, who now ask about patching and unsupported software when they price a policy.

Where the cost lands

The agency head answers for three consequences of an emergency patch: the mission risk if it is missed, the cost of the scramble to apply it, and the accountability for the result.

The first is mission risk. A flaw that lets attackers forge certificates could let them disguise malicious software as legitimate, or impersonate an agency’s website to the public. The consequences of that, from stolen data to fraudulent benefit claims to a loss of public trust, belong to the agency head, not to the server team.

The second is cost. Every emergency directive consumes staff time that was planned for something else. Agencies with weak inventories pay that cost again with each new flaw, because each response starts from scratch. Investment in inventory and automated reporting is a fixed cost that reduces a recurring one.

The third is accountability. When a CIO attests to completion, the agency is making a formal claim to an oversight body. If that claim later proves wrong, because a forgotten server was compromised, the reputational damage is far greater than the original flaw would have caused. Inspectors general, auditors and, for private organizations, regulators and insurers increasingly ask how an organization knows it patched, as well as whether it did.

The second consequence, cost, is not spread evenly. It falls hardest on the small number of engineers who know the oldest and most fragile systems. Each emergency pulls them away from planned work, including the replacement projects that would shrink the next emergency. Agencies that track how many staff hours each directive consumes can make that trade-off visible to the people who set budgets.

Second-order effects

An emergency directive also reorders everything else. The next monthly bundle of fixes arrived less than two weeks after the January deadline, so teams that ran late on one cycle started the next one behind. Planned projects slip in a month like that. Users asked to restart repeatedly tend to grow less patient with the next request. Change boards that waive their usual review for an emergency then have to decide which waivers to keep. Each of these is minor alone. Together they explain why organizations with weak foundations find that every emergency leaves them a little further behind.

The case that this was routine

A fair objection is that January 2020 turned out well. No widespread exploitation of the CryptoAPI flaw was reported. Many machines received the update automatically. On that reading, the directive was a prudent precaution, and the scramble it caused says little about real risk.

The objection misses what the directive revealed. The patch was easy; the inventory, ownership and reporting gaps it exposed were the same ones any later flaw would hit. Later in 2020, CISA issued another emergency directive for a Windows flaw known as Zerologon, which attackers did exploit. Agencies that had fixed their inventory after January were better placed. Those that had treated January as a one-off started again from scratch.

Ready before the next directive

An organization ready for the next emergency patch tends to share a few traits. Its inventory covers contractor-operated and cloud systems as well as the desktops central IT manages, and each entry has a technical and business owner. It has written rules for patching speed by type of system, agreed with mission leaders in advance. It has an expedited change process for emergencies. It verifies patches on the device rather than trusting deployment reports. It tracks unsupported software as its own risk, with replacement dates and signed acceptances. And its status reports come from systems, not spreadsheets.

The usual failures mirror those traits.

• The inventory is treated as an IT spreadsheet rather than as an operational tool.
• The security team assumes it can reboot any system without asking anyone.
• Someone discovers during the emergency that the change board meets on Thursdays.
• A patch counts as done when it has been sent, not when it has been installed.
• Extended support is renewed year after year as though it were a plan.
• The busiest engineers are asked to compile the reports.

State and local agencies are not bound by federal directives, but they face the same questions from state CIOs, auditors and cyber insurers. Banks and hospitals face them from examiners and accreditors. The four capabilities are the same, and so is the order in which to build them: inventory and ownership first, because the other three depend on it.

A handful of measures show whether that work is moving. The first is the share of discovered devices that appear in the official inventory. Others are the share of inventory records with both a technical and a business owner, and the median days to deploy a critical patch by class of system. The rest are the number of systems on unsupported software, with the share carrying a signed acceptance and a funded replacement date, and the hours spent compiling the last outside report. Each can be started without new tools, and each improves the answer on the day of the next directive.

A sequence for the first year

For an organization starting from a weak position, a year is enough to change the answer. The first quarter goes to reconciling the inventory lists and recording owners for critical systems. The second goes to writing the patch-speed rules with mission leaders and setting up the expedited change path. The third goes to device-level verification and automated reporting. The fourth goes to the unsupported-software register, with replacement dates and budget requests. Each quarter delivers something useful even if the next one slips.

Patch readiness the CIO should be able to show

1. If a critical flaw were announced in a common piece of software this morning, could we produce a complete list of affected systems by the end of the day?
2. What share of the devices we can see on our network appear in our official inventory, and does it include systems run by contractors and in the cloud?
3. For each critical system, do we know both the technical owner and the business owner who can approve a restart?
4. When we say a system is patched, have we checked the system itself, or are we trusting the deployment tool?
5. How many systems are we running on unsupported software, who has signed off on that risk, and when will each be replaced?

With hindsight

Emergency Directive 20-02 was an early example of a model that is now routine. In November 2021, CISA issued Binding Operational Directive 22-01, creating the Known Exploited Vulnerabilities catalog and requiring federal civilian agencies to remediate listed vulnerabilities within set timeframes. The catalog is a public list of software flaws that attackers are known to be using in the real world. That makes it a practical guide to what to fix first among thousands of possible fixes. Flaws given CVE numbers from 2021 onward generally had to be fixed within two weeks of listing, and older ones within six months. Patch speed turned into a standing, measured obligation rather than an occasional emergency, and many state agencies, banks and hospitals now use the same catalog to set their own priorities.

ED 20-02 itself was later closed, with its requirements for the January 2020 Windows flaws carried into BOD 22-01. Agencies are still expected to have remediated them wherever updates are available.

The inventory problem drew a directive of its own. Binding Operational Directive 23-01, issued in October 2022, required agencies from April 3, 2023 to run automated asset discovery every seven days. They also had to start vulnerability enumeration on all discovered devices, including roaming laptops, every 14 days. The results had to flow into the CDM dashboard. In effect, CISA turned the question agencies scrambled to answer in January 2020 into a weekly obligation.

The CryptoAPI flaw itself is remembered less for exploitation than for the unusual public role the NSA played in disclosing it. That is in some ways the good outcome: a serious flaw found by defenders, fixed by the vendor and patched under a firm deadline. The NSA went on to report other flaws publicly, including several in Microsoft Exchange Server that Microsoft fixed in April 2021.

The inventory problem held up. Later emergency directives, from SolarWinds Orion in December 2020 to Ivanti Connect Secure in early 2024, again began by asking agencies to find every instance of a product. In September 2025, Emergency Directive 25-03 told agencies to identify all Cisco ASA and Firepower devices in operation, whatever the version, as part of the response to an exploitation campaign. The same directive told agencies to permanently disconnect ASA hardware models whose support ended on or before September 30, 2025, joining the two problems this article describes. Each time, the first and hardest step was the same as in January 2020: knowing where the product was running and who was responsible for it. Federal auditors have kept reporting incomplete asset inventories as a recurring weakness.

What did not hold up was any hope that emergencies would grow rarer as patching improved. Directives kept coming, for Microsoft Exchange in March 2021 and the Log4j logging library in December 2021, among others. Most concerned servers, edge devices and widely embedded software rather than desktops, which are the hardest assets to inventory.

Unsupported systems also persisted longer than plans assumed, which is why end-of-life tracking is now a routine audit question. Paid extended updates for Windows 7 ran out in January 2023, so anything still running it after that date was beyond routine fixes. The machines that could not be patched in 2020 did not disappear on their own; they had to be found, funded and replaced.

The cycle then repeated. Windows 10 reached its end of support on October 14, 2025, and Microsoft again offered paid extended security updates, priced to rise each year for organizations. Agencies, banks and hospitals that had built an end-of-life register after Windows 7 could see their exposure and plan for it. Those that had not met the same problem a second time, with a far larger installed base.

Emergency patching turns out to be an organizational skill more than a technical one. The agencies and companies that respond well are those that already know what they own, who owns it, what the rules are and how to prove the result. Those capabilities are built in calm months, and they pay off on the day the next directive lands.