Why a Windows crypto patch was an asset inventory test
CISA gave agencies ten business days to patch a Windows cryptographic flaw, on the day Windows 7 support ended. Applying the fix was the easy step. Knowing which systems needed it, who owned them and how to prove it was the hard one.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On January 14, 2020, Microsoft released its monthly security updates. They included a fix for a flaw in the Windows CryptoAPI (CVE-2020-0601) that could let an attacker spoof code-signing and TLS certificates on Windows 10 and recent Windows Server versions. They also fixed serious Remote Desktop Gateway flaws. Unusually, the National Security Agency publicly confirmed that it had found and reported the flaw. The same day, the Cybersecurity and Infrastructure Security Agency issued Emergency Directive 20-02. Federal civilian agencies had to apply the January updates to affected endpoints within 10 business days, by January 29, file an initial status report within three, and have their CIOs attest to completion. January 14 was also the end of extended support for Windows 7 and Windows Server 2008, leaving organizations still running them without routine security fixes unless they paid for extended updates.
Emergency Directive 20-02 read like a patching instruction. 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. The other four were.
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. 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. Where that share is low, every directive starts with a hunt.
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.
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 quiet month. Ten business days leaves no time to negotiate them.
Change boards are a frequent bottleneck. 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. 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. 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 quietly, because replacement is a capital decision and patching is an operational one, and the two sit in different budgets. 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.
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. 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. 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.
State and local agencies are not bound by federal directives, but they face the same questions from state CIOs, auditors and cyber insurers. 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.
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. 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.
The CryptoAPI flaw itself is remembered less for exploitation than for the unusual public role the NSA played in disclosing it. 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. Federal auditors have kept reporting incomplete asset inventories as a recurring weakness. Unsupported systems also persisted longer than plans assumed, which is why end-of-life tracking is now a routine audit question.