Executive Order 14028 gave zero trust three testable demands

The week

In the second week of May 2021, Americans on the East Coast were lining up at gas stations. Colonial Pipeline, which carries fuel up the coast, had been hit by ransomware on May 7. Ransomware is malicious software that scrambles an organization’s files and systems so they cannot be used, followed by a demand for payment to unlock them. Colonial shut its pipeline down as a precaution, and that same week it restarted operations, beginning on May 12.

The scale explained the queues. Colonial has described its system as carrying roughly 45 percent of the fuel consumed on the East Coast. On May 10, the FBI publicly attributed the attack to DarkSide, a criminal ransomware group that rented its malware to affiliates. Colonial paid a ransom of about 75 bitcoin, then worth roughly $4.4 million. In June, the Justice Department announced it had seized about 63.7 bitcoin of that payment, worth about $2.3 million by then after a fall in the bitcoin price.

The shutdown was a choice. According to Colonial’s own account, the ransomware hit business systems, not the systems that physically control the flow of fuel. The company stopped the pipeline because it could not be sure the attack would stay contained, and because the business systems it lost were tied to scheduling and billing. A business-network compromise had become a physical supply problem.

The attack landed on a government already uneasy. Months earlier, investigators had discovered the SolarWinds compromise, in which attackers slipped malicious code into a widely used piece of network management software and, through its routine updates, gained a foothold inside many organizations, including federal agencies. In March 2021, attackers had also exploited newly disclosed flaws in on-premises Microsoft Exchange email servers, hitting large numbers of organizations within days.

On May 12, 2021, President Biden signed Executive Order 14028, Improving the Nation’s Cybersecurity. An executive order is a directive from the president to the federal executive branch; it binds agencies, not private companies, but it often shapes what the government buys and, through that, what the market sells. The order had been in preparation since the SolarWinds discovery; Colonial gave it urgency and an audience.

This one was unusually concrete. It directed federal civilian agencies to adopt multi-factor authentication within 180 days. Multi-factor authentication means proving who you are with more than a password, such as a code from your phone or a physical key. The same deadline applied to encryption of data at rest and in transit, meaning information is scrambled both while it sits in storage and while it travels across networks, so that a thief who grabs it gets gibberish. Agencies that missed the deadline had to explain why in writing.

The order told agencies to develop plans for zero trust architecture within 60 days. Zero trust is an approach in which no user or device is trusted automatically just because it is inside the office network, and to move toward secure cloud services. It tasked NIST, the National Institute of Standards and Technology, with guidance on secure software development, including the software bill of materials, an ingredients list for software. NIST was given 45 days to define “critical software,” and the Commerce Department 60 days to publish the minimum elements of a software bill of materials. It required that software sold to the government meet new security standards, and it asked for pilot labeling programs for consumer devices and software.

It also created a Cyber Safety Review Board, modeled loosely on the idea of investigating serious incidents to learn from them, with members from federal agencies and the private sector. Its first assignment was the activity behind the December 2020 response that followed SolarWinds. The order called for a standard incident response playbook within 120 days, so agencies would handle attacks in a consistent way. It required endpoint detection and response, software that watches laptops and servers for suspicious behavior, across agencies.

Section 2 dealt with a complaint investigators had made for years: IT service contracts that limited what providers could tell the government about incidents. The order directed changes to federal acquisition rules so that providers would collect and share incident data. For the most severe incidents, it called for reporting within no more than three days of detection.

Finally, it directed OMB, the Office of Management and Budget, to set requirements for logging and log retention: what records of computer activity agencies must keep, and for how long. And it started work on changes to federal contract rules, so that companies running IT for agencies would have to report incidents and share data with investigators. National security systems were handled in a separate section, through the Defense Department and the intelligence community.

Within weeks, the government also moved on Colonial’s own sector. In late May, the Transportation Security Administration issued a security directive requiring designated pipeline operators to report cybersecurity incidents to CISA and to name a cybersecurity coordinator. The executive order was the federal government governing itself. The pipeline directive showed it was prepared to reach into private infrastructure as well.

After SolarWinds, many organizations could not answer the basic questions that follow any intrusion: who got in, how they got past the sign-in, what they touched, and whether the software itself was compromised when it was installed. Without sign-in records, activity logs or knowledge of where their software came from, they were left guessing about how bad things were.

Executive Order 14028 was the federal government’s attempt to make sure it would never again be left guessing. 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. Vendors used it the way food companies use “natural.” 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.

The article first sets out what zero trust means in architectural terms, then takes the three demands in turn. It closes with why they only work together, how a federal order reached banks, hospitals and counties, and what a program that meets the tests looks like and can show.

What zero trust actually means

For decades, most organizations protected their computers by guarding the network perimeter, the boundary between the organization’s internal network and the public internet, and assuming everyone inside it was friendly. Once you were inside, by sitting at an office desk or by connecting through a VPN (a virtual private network, which creates a protected tunnel from a remote laptop into the office network), you were largely trusted.

The weakness of that model is obvious once stated. An attacker who steals one employee’s password, or tricks one person into opening a booby-trapped attachment, is now inside, and the perimeter no longer helps. Modern attackers rarely break through the perimeter; they borrow a key.

Zero trust flips the assumption. Instead of trusting anyone inside the network, it asks every request to prove itself, every time, based on who is asking, from what device, for what purpose. Being inside the network gets you nothing on its own; each application checks.

The decision point

NIST had published its reference description of zero trust architecture in August 2020, as Special Publication 800-207. It describes a policy decision point, which weighs each access request against rules and signals, and an enforcement point, which lets the request through or blocks it. Signals can include the user’s identity, the strength of the sign-in, the health of the device, the sensitivity of the data and unusual behavior.

That model is useful because it makes zero trust concrete. For every application, an organization can ask where the decision is made, what signals it uses and what enforces it. If the answer is “the VPN let them in and the application trusts the network,” the application is still running on the old model.

What zero trust does not mean

Three misreadings are common. Zero trust does not mean removing firewalls or network controls; those still limit where an attacker can go. It does not mean distrusting employees as people; it means the system no longer grants access on the basis of location alone. And it is not a product. A vendor can supply components, such as an identity platform or a proxy, but the architecture is a set of decisions about how every application grants access.

Getting the definition right matters for budgets. A program described as a product purchase ends when the invoice is paid. A program described as an architecture continues application by application until the inventory is done, and needs funding to match.

Why it took an order

The difficulty is that real organizations run systems built by different contractors in different decades. Some can be fitted with modern sign-in. Some cannot. Executive Order 14028 forced agencies to go through every system and find out which was which.

Budgets and incentives had worked against that inventory for years. Each system had its own owner, contract and funding line. A security office could recommend changes, but it rarely controlled the money to make them. Deadlines signed by the president, with reporting to OMB every 60 days, changed the conversation inside agencies. A program manager who had deferred modern sign-in for years now had to explain the delay to people with budget authority.

CISA later published a Zero Trust Maturity Model to help agencies measure progress, organized around identity, devices, networks, applications and workloads, and data. The three demands in this article cut across those pillars. Identity and devices map to the first demand. Visibility is a capability every pillar must produce. Supply chain applies to the applications and workloads an organization runs.

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.

Those terms deserve a moment. Phishing is the practice of tricking someone into handing over their credentials, usually through a convincing fake email or web page. Ordinary multi-factor authentication, such as a six-digit code sent by text message, helps, but a skilled attacker can build a fake login page that asks for the code too and passes it along in real time. Phishing-resistant methods close that gap. A PIV card (Personal Identity Verification, the smart card many federal employees carry) and a FIDO2 security key (a small device that plugs into a laptop or taps against a phone) both use cryptography tied to the genuine website, so they simply will not work on a fake one.

The long tail of applications

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.

An identity-aware proxy is a gatekeeper that sits in front of an older application. Users sign in to the gatekeeper with modern, strong authentication, and only then does the gatekeeper let them through to the old system, which never has to change. The trade-off is that the old system still trusts whatever reaches it. If an attacker finds another route to the application, around the proxy, the protection disappears. Proxies work best when the network also blocks every other path.

Accounts that are not people

Service accounts are the hardest category. These are accounts used by software to talk to other software: a nightly batch job, a backup tool, a reporting system pulling from a database. They cannot use a security key, and their passwords are often old, shared and widely known. Attackers prize them for exactly that reason.

The workable approach is to find them, assign each an owner, restrict where it can be used from, rotate its credentials automatically through a vault, and watch its activity closely. That is slow, detailed work, and it rarely appears on a vendor’s zero trust slide.

Devices as the second factor

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.

Contractors and partners complicate this. Many people who need access to agency systems use devices the agency does not manage. The choices are to issue managed devices, to require a virtual desktop that keeps data off the unmanaged machine, or to allow limited access with fewer privileges. Each choice has a cost in money or convenience, and each should be made deliberately.

The friction question

Stronger authentication can provoke resistance. Staff who already juggle many passwords see another step in their day. Help desks fear a flood of lockouts. M-22-09 tackled part of this directly: it told agencies to stop requiring special characters and regular password rotation, practices that frustrate users without adding much security. Single sign-on, where one strong authentication opens many applications, can make the stronger model easier for staff than the old one.

Weaker methods also showed their limits after 2021. Attackers learned to bombard users with push notifications until someone approved one out of fatigue, a tactic used in several widely reported breaches in 2022. That pattern strengthened the case for the phishing-resistant methods the federal strategy had chosen, over simpler approval prompts.

The identity test at county scale

Suppose a county government with about 4,000 staff applies the identity test. The IT team lists its critical applications and finds three kinds. The email and document systems already support modern sign-in, so they simply switch on phishing-resistant keys for staff. The permitting system, built fifteen years ago, keeps its own list of usernames and passwords; it goes behind an identity-aware proxy while a replacement is planned. A small reporting tool used by four people and duplicated elsewhere is retired. The steps are unglamorous, but at the end the county can say, for each system, exactly how a person proves who they are before getting in.

The county’s sheriff’s office adds a constraint. Systems that handle criminal justice information fall under the FBI’s CJIS Security Policy, which sets its own authentication requirements. The county’s identity program has to meet that policy for those users, and auditors from the state will check it.

Visibility: logs as evidence, not exhaust

A log is a time-stamped record of something that happened on a computer system: someone signed in, a file was opened, a setting was changed, a program started. Systems produce enormous numbers of them. For years many organizations treated logs as exhaust, a by-product to be discarded after a few days or weeks to save storage costs.

The SolarWinds investigations had shown that many organizations lacked the logs to know what an intruder had done. Without records, an organization cannot tell regulators, customers or its own board what was taken, which leaves everyone assuming the worst. The order responded by requiring endpoint detection and response across agencies and directing OMB to set logging rules.

Endpoint detection and response, usually shortened to EDR, is software installed on each laptop and server (each “endpoint”) that watches for suspicious behavior, such as a program trying to copy passwords in the background, and can alert a security team or isolate the machine.

Maturity tiers and retention

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. Further time in cheaper cold storage came on top. “Active storage” means the records are kept where they can be searched quickly, not archived on slow media that take days to restore. Agencies were given two years to reach the most advanced tier.

The tiers matter because they separate collecting logs from using them. The basic tier is about gathering the most important records. Higher tiers add standardized formats, protection of the records, automated analysis and behavior baselines, so that unusual activity stands out. An agency can hold a mountain of logs and still sit at the bottom if nobody can search them quickly.

Where the money goes

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, the Cybersecurity and Infrastructure Security Agency. Protection from tampering matters because a capable intruder’s first instinct is often to erase their tracks; logs that the intruder can delete are not evidence.

Cost control is a design problem rather than a reason to collect less. Security teams can route high-value logs, such as sign-ins, administrator actions and EDR alerts, to fast and expensive search. Bulkier, lower-value records can go to cheaper storage that is still retrievable within hours. The decision about which log goes where should be made by people who have actually worked an incident, because they know which records were needed.

Clocks, formats and integrity

Logs are only useful as evidence if they can be lined up and trusted. That depends on mundane details. Every system needs an accurate, synchronized clock, or the sequence of events across systems cannot be reconstructed. Records need consistent formats and identifiers, so that the same user appears under the same name in the sign-in logs, the EDR alerts and the cloud audit trail.

Integrity needs separation. Logs should flow to a store that the administrators of the source systems cannot alter, ideally with write-once settings or cryptographic checks that reveal tampering. An attacker who takes over a domain administrator account should not also own the evidence of what that account did.

Cloud and SaaS records

Visibility also meant cloud and software-as-a-service logs, which many agencies had not been collecting at all. Software as a service, or SaaS, is software you rent and use over the internet rather than install yourself; email, payroll and customer-relationship systems are common examples. The provider runs the machines, which also means the provider holds the records of what happens on them. 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.

Contracts are the lever. A cloud agreement can specify which logs the provider will make available, in what format, for how long, and how quickly during an incident. Few contracts in 2021 said any of that. Procurement and legal teams, rather than only security teams, decide whether the organization will be able to see what happened in a rented system.

Evidence for whom

Logs serve several audiences with different needs. Security analysts need them in minutes to stop an attack. Investigators need them complete and untampered to reconstruct it. Lawyers need them to decide whether notification duties apply. Regulators and auditors need evidence that the controls work. A logging design that serves only the first audience will disappoint the others.

Supply chain: knowing what is inside the software

The third demand was the most novel. Modern software is rarely written from scratch. A typical application is assembled from hundreds of smaller components, many of them open source, meaning free code written and maintained by outside communities. That is efficient, but it means an organization buying one product is also, invisibly, trusting every component inside it and every developer who touched them. SolarWinds showed what happens when that trust is abused at the source.

Attestation

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. An attestation is a formal, signed statement that a company does what it says; it creates accountability because a false statement has consequences.

The framework covers practices such as protecting the build environment, reviewing code for vulnerabilities, controlling who can change source code, and having a process to respond to reported flaws. The SolarWinds attack had targeted the build process itself, the step where source code becomes the product customers install. Protecting that step was the direct answer.

The Justice Department added weight in October 2021 with a Civil Cyber-Fraud Initiative, which uses the False Claims Act against contractors that knowingly misrepresent their cybersecurity practices. A signed attestation becomes far more serious when a false one can lead to liability under that law.

The software bill of materials

The order also promoted the software bill of materials, or SBOM, a machine-readable list of components inside a product, so that buyers could tell quickly whether a newly disclosed vulnerability affected them. The best analogy is the ingredients label on packaged food. If a food safety alert names a contaminated ingredient, a shopper with labels can check the pantry in minutes. Without labels, every jar is a mystery.

The Commerce Department’s minimum elements, published in July 2021, set out the basic data fields. Those are who supplied each component, its name and version, and a unique identifier. They also include how it relates to other components, and who wrote the SBOM and when. They also called for formats that machines can read, such as the established SPDX and CycloneDX standards.

Procurement and the query

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.

Supply chain duties by type of buyer

The supply chain demand lands differently by sector. A bank or credit union depends heavily on a small number of core processing and digital banking providers. US banking regulators issued joint guidance on third-party relationships in June 2023, which expects banks to manage the risk of those providers across the relationship’s life. Component transparency and secure development practices fit naturally into that due diligence.

A health system faces the question through medical devices as well as software. Since 2023, federal law has required manufacturers seeking FDA clearance for many networked medical devices to include a software bill of materials in their submissions. Hospitals can ask for those lists and load them into the same repository as their other software.

A state or local agency usually buys through cooperative contracts and resellers, which can put several layers between it and the software maker. It may need to write SBOM and attestation requirements into master agreements, so that individual departments inherit them.

The case against SBOMs, and its limits

Critics raised fair objections. An SBOM lists components, but most vulnerable components in a product are never actually reachable by an attacker. A raw match produces many false alarms. Industry and CISA responded with the idea of a vulnerability exploitability exchange, a companion statement in which a supplier says whether a given flaw actually affects its product.

Vendors also worried that component lists would reveal proprietary design or hand attackers a map. And attestation is self-attestation: the government cannot inspect every supplier’s build process. These objections limit what SBOMs and attestations can do. They do not remove the core benefit, which is speed when a widely used component turns out to be dangerous. An organization that can list affected systems in hours makes better decisions than one that needs weeks.

Why the three demands only work together

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.

SolarWinds itself illustrates all three. The malicious code arrived through a trusted supplier’s update, a supply chain failure. Once inside, the attackers worked to obtain credentials and tokens that let them access cloud email, an identity failure. Many victims then struggled to determine what had been accessed, a visibility failure. A fix for any one of the three would have helped. A fix for all three would have changed the outcome.

Colonial itself fit the pattern. Its chief executive told a Senate committee in June 2021 that the attackers had entered through a legacy VPN account that did not require multi-factor authentication. A password alone, on an old account that should have been retired, opened the door to a business network, and from there to a fuel shortage. Better identity controls would have closed that door; better visibility would have shown someone walking through it.

Treating zero trust as a product purchase misses this. A vendor can sell an authentication tool, a logging platform or an SBOM scanner, and each may be good. None of them, alone, answers the question a board actually cares about: if something goes wrong in our most important system, will we stop it early, know what happened, and know whether the fault came from our own people or from a supplier?

Sequencing

Programs still have to start somewhere. Identity usually comes first, because stolen credentials are the most common way in and the controls are mature. Visibility follows closely, since it is needed to prove the identity controls work and to investigate when they fail. Supply chain work runs alongside through procurement, because contracts renew on their own schedule and each renewal is a chance to add requirements.

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?

Federal rules, private-sector consequences

The order bound federal agencies, but its reach was wider. The government is a very large buyer of software, so requirements placed on federal suppliers tend to become features of the products everyone else buys. And the three tests map neatly onto the things that worry boards in any sector.

Which rules reach whom

The rules that reach each sector differ, and the three tests help translate between them. Banks and credit unions are examined against the FFIEC’s guidance, which in August 2021 issued updated guidance on authentication and access to financial institution services and systems. Firms regulated by the New York Department of Financial Services face Part 500, whose November 2023 amendments extended multi-factor authentication requirements across their systems on a phased schedule.

Broker-dealers and investment advisers answer to the SEC, whose 2024 amendments to Regulation S-P added incident response and customer notification requirements. Health systems and their business associates fall under the HIPAA Security Rule, which HHS proposed to update in early 2025 with explicit multi-factor authentication requirements; organizations should confirm its current status with counsel. Defense contractors face the Cybersecurity Maturity Model Certification program, which the Defense Department finalized in late 2024. State and local agencies are not bound by the order, but those handling criminal justice information must meet the CJIS Security Policy, and many follow federal practice when they use federal grants.

What boards should weigh

Money. Logging and retention cost real money, and some of it hides in license tiers. Leaders who understand the requirement can budget for it deliberately, instead of discovering the gap in the middle of an incident.

Risk. Stolen credentials are among the most common ways attackers get in. Phishing-resistant authentication shrinks that risk more than almost any other single measure, which is why it was the first deadline.

Customers and reputation. After an incident, the organization that can say precisely what happened, and what did not, keeps more trust than the one that can only say “we are investigating.” Logs are what make the precise answer possible.

Regulators. Banking, healthcare and public-sector regulators increasingly expect organizations to show how they verify access, monitor systems and manage suppliers. The three tests give a common structure for that conversation.

Staff. Done well, stronger authentication can actually be easier for employees than juggling many passwords. Done badly, it piles friction on people who just want to do their jobs, and they find workarounds.

The counter-argument from smaller organizations

A credit union with a small IT team, or a rural county, might reasonably say that federal-scale zero trust is beyond its means. The objection is fair about the full architecture. It is weaker about the three tests. Phishing-resistant sign-in for administrators and email, a year of searchable sign-in and administrator logs, and an SBOM requirement in the next core-system contract are within reach of most organizations. Many of the platforms they already rent include these features, sometimes at a higher license tier. The tests scale down; the architecture diagram does not need to.

Sequencing for a mid-size organization

For a regional bank, a mid-size health system or a state agency, a realistic first year looks similar. Phishing-resistant authentication goes to administrators and remote access first, then to email for everyone. Sign-in, administrator and EDR logs go to central, protected storage with a year of searchable retention. Every new software contract and renewal carries a clause on component lists, secure development and log access. The second year extends each line to the next tier of systems. The pace is set by contracts and staff, not by technology.

A living inventory and a stopwatch

The strongest programs keep a living inventory. A regional bank doing this well can produce, for each of its critical systems, a one-page answer: how people sign in, which devices are allowed, where the logs go and how long they are kept, and which supplier components are inside. The page is updated when things change, and senior leaders see a simple summary of how many systems meet each test.

Owners and evidence

Each line on the page has an owner. The identity team owns sign-in. The security operations team owns log collection and retention. Procurement and vendor management own SBOM and attestation requirements in contracts. Application owners own the decision to modernize, proxy or retire. Internal audit tests a sample each year and reports exceptions.

The evidence an examiner or auditor would ask for follows from the page. It includes configuration exports showing which applications enforce strong sign-in, retention settings for each log source, contract clauses on logs and SBOMs, and records of the drills below. A program that can hand those over quickly tends to have a shorter examination.

Drills against the clock

The strongest programs also rehearse. The team has actually run the drill: a hypothetical new vulnerability is announced, and someone times how long it takes to find every affected system using the SBOM repository. Another drill pulls the logs for a staged suspicious sign-in and reconstructs what that account did. A third revokes a compromised account and checks how long it takes for every application to stop honoring its sessions.

Each drill produces a number. The numbers become the metrics leaders track: hours to find an affected component, hours to reconstruct an account’s activity, minutes to cut off access. They improve when the architecture improves, which is why they are better measures than counts of tools deployed.

Where programs fail

The weaker programs fail in predictable ways:

• Buying a label. Purchasing a product marketed as zero trust and declaring the job done, while the old applications still accept a simple password.
• Collecting logs nobody can search. Storing huge volumes in a place that is cheap but slow, so that during an incident it takes days to answer a basic question.
• Forgetting the cloud. Watching the office network closely while the most sensitive data has moved into rented cloud services whose logs nobody collects.
• Filing SBOMs as paperwork. Accepting component lists as attachments to contracts that no system can read.
• Ignoring the exceptions. Leaving shared accounts and vendor portals outside the program because they are awkward, which is exactly where attackers look.
• Accepting push approvals as strong. Treating any multi-factor prompt as sufficient for administrators, when only phishing-resistant methods hold up against determined attackers.

What the security chief should be able to show

A leader does not need to understand the technical details to hold a team to these standards. These questions work in a board meeting, a quarterly review or a one-to-one with a chief information security officer:

1. For our ten most important systems, how does a person prove who they are before getting in, and which of those systems still rely on a password alone?
2. If we discovered an intruder today, how far back could we see what they did, and could they have erased those records?
3. Are we collecting the activity records from our cloud and software-as-a-service providers, and are we paying for the license level that includes them?
4. When the next Log4j-style flaw is announced, how many hours would it take to list every affected system? Have we tested that?
5. Do our software contracts require suppliers to provide a component list and to attest to secure development practices?

The answers will not all be good, and that is fine. The three tests exist to turn a vague promise to be “secure” into a list of specific systems and specific gaps, each with an owner and a date. A leader who asks the same five questions every quarter will see whether the gaps are closing.

With hindsight

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. That unevenness is itself instructive: the same instructions, deadlines and guidance produced very different results depending on how much old technology each agency carried and how seriously its leaders treated the work.

The early deliverables arrived largely on schedule. NIST published its definition of critical software in June 2021, and the Commerce Department published the minimum elements for an SBOM in July. CISA released standard incident and vulnerability response playbooks for agencies that November. OMB issued the logging memorandum in August 2021 and the zero trust strategy in January 2022.

The logging work proved the hardest. In December 2023, the Government Accountability Office reported on agencies’ status as of August 2023. Only 3 of the 23 large civilian agencies it reviewed had reached the most advanced logging tier OMB required by that date. Seventeen were still at the lowest tier. Visibility was the demand that cost the most and moved the slowest, which fits what the article argued about its expense.

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. The agency that spotted the intrusion could see it because it was paying for the records that revealed it; others at a lower tier could not. Microsoft later broadened access to those logs. It is a vivid reminder that the ability to see an attack can depend on a line item in a contract.

CISA updated its Zero Trust Maturity Model in April 2023, adding an initial stage that made it easier for organizations starting from a low base to measure themselves honestly.

On the supply chain, NIST published the Secure Software Development Framework in early 2022. OMB then required agencies to collect attestations from software producers, and CISA published a secure software development attestation form in 2024. SBOMs are now a routine expectation in many procurements. What began as an unfamiliar idea in a 2021 order has become an ordinary question in a buyer’s checklist, which is how security improvements usually spread: first required, then expected, then assumed.

The identity demand spread fastest beyond government. Financial regulators moved on authentication in the same period, through the FFIEC’s 2021 guidance and New York’s 2023 amendments to Part 500. The push-notification fatigue attacks of 2022 vindicated the federal choice of phishing-resistant methods over simpler prompts.

The Cyber Safety Review Board produced influential reports, including on Log4j and Storm-0558, before its membership was ended in early 2025. Its Storm-0558 report was sharply critical of the security practices that allowed the intrusion. Executive orders in January and June 2025 built on and then amended parts of the framework, with the June order striking several of the January order’s software security provisions, so organizations relying on specific provisions should check their status.

Some parts moved far more slowly. The contract changes meant to make IT service providers report incidents and share data did not appear as proposed acquisition rules until October 2023, more than two years after the order. The pipeline security directives that followed Colonial were revised after operators objected that they were too prescriptive, and in 2022 TSA moved toward a more performance-based approach. The pattern was consistent: requirements on the government itself moved faster than requirements on the private companies it depends on.

What held up is the architecture; what proved fragile is the policy machinery around it. The three tests have survived changes of administration, while specific deadlines, boards and attestation rules have shifted.

The specific federal rules have shifted and may shift again. The three underlying tests have not. Whether or not any order requires it, an organization that can say how access to each critical system is verified, what evidence that system produces, and where its software came from is in a far stronger position to contain an incident, explain it to regulators and customers, and recover its reputation. Those are questions of good management, and they outlast any particular administration’s policy.