Executive Order 14028 gave zero trust three testable demands

Signed days after the Colonial Pipeline attack, the May 2021 cybersecurity order turned a marketing term into three demands any agency can test system by system: verified identity, retained evidence, and accountable software supply chains.

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 May 12, 2021, President Biden signed Executive Order 14028, Improving the Nation’s Cybersecurity. It came the same week Colonial Pipeline, hit by ransomware on May 7, restarted operations, and months after the SolarWinds compromise had been discovered. The order directed federal civilian agencies to adopt multi-factor authentication and encryption of data at rest and in transit within 180 days, to develop plans for zero trust architecture, and to move toward secure cloud services. It tasked NIST with guidance on secure software development, including the software bill of materials, and required that software sold to the government meet new security standards. It also created a Cyber Safety Review Board, called for a standard incident response playbook, required endpoint detection and response across agencies, and directed OMB to set requirements for logging and log retention.

Cybersecurity executive orders were not new in 2021. This one stood out for specificity: deadlines, named deliverables and assignments to particular agencies. Its most quoted phrase, zero trust, had by then been applied to almost every security product on the market. The order gave the term content by tying it to three architectural demands that any organization, federal or not, can test: identity, meaning every access decision rests on a strongly verified user and device; visibility, meaning the organization can see and retain evidence of what happens on its systems; and supply chain, meaning it knows what is inside the software it runs and who answers for it. Each demand exposed a different gap in agency architecture, and each depends on the others.

Identity: from network location to verified user and device

Traditional government networks trusted users largely because of where they were: inside the perimeter, on an agency device, behind a VPN. The order’s 180-day deadline for multi-factor authentication was the first step away from that model. OMB’s zero trust strategy, memorandum M-22-09 of January 2022, made the direction explicit. It called for phishing-resistant authentication, such as PIV cards or FIDO2 security keys, and set agency goals for the end of fiscal year 2024.

The hard part was rarely buying an authentication product. It was the long tail of applications that could not use modern authentication: mainframe systems, older web applications with their own password stores, shared service accounts, and vendor-managed tools reached through separate portals. An identity-centered architecture forced agencies to inventory every application by how users authenticate to it, then choose for each: modernize it, put it behind an identity-aware proxy, or retire it.

Device identity was the second half. Knowing the user is not enough if the laptop is unmanaged or unpatched. Agencies needed device inventories tied to their identity systems, so that access decisions could consider device health. For many, the device inventory was less complete than the user directory, and closing that gap was slow.

Visibility: logs as evidence, not exhaust

The SolarWinds investigations had shown that many organizations lacked the logs to know what an intruder had done. The order responded by requiring endpoint detection and response across agencies and directing OMB to set logging rules. OMB’s memorandum M-21-31, issued in August 2021, defined maturity tiers for event logging, listed which logs to collect, and set retention periods, including 12 months in active storage for many log types.

That turned logging into an architectural requirement with real cost. Storing and searching the required volume is expensive, and many agencies found their tools were not built for it. The design questions became where logs would be centralized, how they would be protected from tampering by an intruder with administrator rights, and how quickly they could be shared with incident responders, including CISA.

Visibility also meant cloud and software-as-a-service logs, which many agencies had not been collecting at all. Some logging features in commercial cloud services were sold only at higher license tiers, which turned visibility into a procurement question. That gap drew public attention two years later.

Supply chain: knowing what is inside the software

The third demand was the most novel. The order asked NIST to define secure software development practices, which became the Secure Software Development Framework, and directed that vendors selling software to the government attest to following them. It also promoted the software bill of materials, a machine-readable list of components inside a product, so that buyers could tell quickly whether a newly disclosed vulnerability affected them.

For agencies, this changed procurement. Software purchases now had to weigh the supplier’s development practices and transparency alongside features and price. For vendors, it introduced formal accountability that had not existed before. The value of an SBOM was clear in December 2021, when the Log4j vulnerability forced every organization to ask which of its systems contained a particular open source library. Many could not answer for weeks.

An SBOM has value only if someone can query it. Receiving component lists as PDFs attached to contracts does little. The useful capability is a repository that ingests SBOMs in a standard format, links them to the systems where each product is deployed, and can answer within hours which systems contain a named component. Building that is modest work, and it can be done incrementally, starting with internet-facing and mission-critical systems.

The three demands depend on each other. Strong identity without visibility leaves no evidence when credentials are misused. Visibility without identity produces logs that cannot be tied to real users and devices. Both are undermined if the software is compromised before it arrives, as SolarWinds had shown. Treating zero trust as a product purchase misses this. Measuring it application by application across all three makes progress visible, and the same three tests work for a state agency, a health system or a bank: for each critical system, how is access verified, what evidence does it produce, and what do we know about where its code came from?

With hindsight

Looking back from 2026, Executive Order 14028 shaped federal cybersecurity more than most such orders. Agencies reported substantial progress on multi-factor authentication, endpoint detection and logging, though progress varied widely by agency. The visibility point gained public attention in 2023, when the Storm-0558 intrusion into Microsoft’s cloud email was detected by a federal agency using logs that many customers did not have at their license level; Microsoft later broadened access to those logs. CISA published a secure software development attestation form in 2024, and SBOMs are now a routine expectation in many procurements. The Cyber Safety Review Board produced influential reports, including on Log4j and Storm-0558, before its membership was ended in early 2025. Executive orders in January and June 2025 built on and amended parts of the framework, including softening some software attestation requirements, so organizations relying on specific provisions should check their status.

  • Executive Order 14028
  • zero trust
  • SBOM
  • logging
  • federal cybersecurity