Executive Order 14028 compliance: what federal contractors and vendors actually owe
Sienna VanceApril 29, 2026
Key takeaways
EO 14028 created specific obligations for software vendors in the federal supply chain: SBOM delivery with transitive dependency coverage, signed attestation against named NIST SSDF practices, and availability of supporting artifacts on request — not a general statement of security maturity.
OMB M-22-09 required phishing-resistant MFA for federal agency staff by end of FY2024, which means hardware security keys or PIV credentials — SMS-based MFA does not satisfy the requirement regardless of whether it appears in a compliance checklist as MFA-enabled.
SBOM submissions that list only top-level dependencies do not satisfy the NTIA guidance that EO 14028 implementation relied on. Transitive dependencies — libraries used by libraries — must be included, and most SBOMs produced for initial compliance do not meet that standard.
When investigators request evidence after a security incident at a covered organization, they ask for raw log data in machine-readable formats, not dashboard screenshots. Organizations that cannot export structured logs with complete field sets face evidence production failures that are separate from the underlying incident.
Software vendor attestations signed against vague language — citing adherence to secure development best practices without mapping to specific SSDF practice identifiers — are not attestations in the sense the CISA form requires, and they create false certification exposure.
TL;DR
EO 14028 is a procurement-facing order more than a direct regulatory mandate. Its bite comes through what federal agencies now require from software vendors: SBOMs that actually cover the full dependency graph, attestations mapped to specific SSDF practices, and logging architectures that produce evidence in formats investigators can use. Most organizations addressed the surface requirements. The depth requirements remain largely unsatisfied three years in.
The attestation that did not hold up
A SaaS vendor holding federal agency contracts completed the CISA software attestation form in 2023. The form was signed by the CISO. It affirmed compliance with the referenced NIST SSDF practices. During a subsequent agency security review, the contracting officer asked for documentation supporting three specific SSDF practices listed on the attestation: PS.3.1 covering archive and protect each software release, RV.1.1 covering gathering information from software acquirers, and PO.3.2 covering implementation of supporting toolchains. The vendor's security team had no artifacts for any of them. The attestation was signed against language the team understood as general best-practice affirmation. It was not.
The CISA attestation form references SSDF practices by their practice identifiers. Each identifier maps to specific outcomes and example implementations in NIST SP 800-218. Signing the form is an assertion that the organization implements those specific practices, not that it has a generally good security program. The vendor had good security practices. They did not have documented evidence of the specific practices the form referenced. Those are different things, and the gap between them is where attestation liability lives.
How EO 14028 actually creates obligations and for whom
Executive Order 14028, signed May 2021, is directed at federal agencies and at entities transacting with the federal government. Section 4 covers software supply chain security and establishes that federal agencies must only acquire software from vendors who attest to their development practices and provide SBOMs. Section 7 covers logging requirements for federal agencies. Section 3 establishes zero trust architecture as the required security model. The direct obligations fall on federal agencies. The practical obligations fall on anyone in the federal software supply chain, because agencies enforce the order's requirements through procurement conditions. A private company with no federal contracts is not subject to EO 14028. A private company with even a single federal software contract is subject to the attestation and SBOM requirements as a condition of sale.
Example
The CISA self-attestation common form, published in 2024, requires vendors to attest that they conform to SSDF practices in four categories: PO (Prepare the Organization), PS (Protect the Software), PW (Produce Well-Secured Software), and RV (Respond to Vulnerabilities). The form lists specific practice identifiers. Attestation means affirming compliance with each listed practice, not affirming general agreement with the framework. A vendor who attests to PW.4.1 — reuse existing, well-secured software — should be able to demonstrate a documented process for evaluating component security before adoption. Most cannot produce that documentation on request.
The SBOM requirement flows from NTIA's minimum elements guidance, published July 2021 and adopted as the federal baseline. The minimum elements include supplier name, component name, version, other unique identifiers, dependency relationships, author of the SBOM data, and timestamp. The dependency relationship field is where depth matters: NTIA guidance specifies that SBOMs should represent the full dependency graph to the extent known. An SBOM that lists a web framework but does not list that framework's cryptographic library dependency — where, hypothetically, a vulnerability exists — satisfies the format requirement and fails the purpose requirement.
What the assessments show about EO 14028 program depth
Assessment base: Vulnox federal contractor and software vendor assessments, 2024-2025
SBOMs that satisfy format requirements but not depth requirements
In assessments of software vendors with federal contracts, SBOM coverage consistently stops at direct dependencies. The vendor runs a dependency scanning tool, exports the top-level component list, formats it to the NTIA minimum elements, and submits it. The transitive dependency graph — which for a typical enterprise web application runs two to four levels deep and can include hundreds of components not visible in the top-level list — is not in the SBOM. No tool flag triggers because the format is correct. The depth gap is invisible to automated validation.
A vulnerability in a transitive dependency — the kind that produced the Log4Shell incident — would not appear in these SBOMs. An agency that relies on the SBOM to assess software risk before deployment or after incident is working from an incomplete inventory. The attestation that accompanied the SBOM affirmed the SBOM was complete.
Logging architecture that produces volume but not evidence
Organizations that deployed centralized logging to satisfy EO 14028 Section 8 requirements frequently routed logs through unencrypted forwarders, stored them in formats requiring manual export, or configured retention periods below what post-incident investigations require. In one assessed environment, logs were forwarded to a SIEM using unencrypted syslog over UDP. Logs existed. The transport mechanism meant log integrity could not be verified, and the data was not usable as evidence in any proceeding where authenticity mattered.
EO 14028 logging requirements exist to support incident response and investigation. Logs that cannot be authenticated, exported in structured format within a response window, or retained long enough to cover the typical dwell time of a sophisticated intrusion do not serve that purpose. The compliance checkbox is checked. The operational capability is not present.
MFA implementations that satisfy the checkbox but not the M-22-09 requirement
OMB M-22-09 required phishing-resistant MFA — specifically, authentication methods that are not susceptible to phishing attacks. SMS one-time passcodes are susceptible to SIM swapping and real-time phishing relays. Standard TOTP authenticator apps are susceptible to real-time phishing relays. Only hardware security keys using FIDO2/WebAuthn and PIV/CAC credentials satisfy the phishing-resistant definition. In assessed federal contractor environments, the majority of MFA deployments use authenticator apps. They are documented as MFA-compliant. They do not satisfy M-22-09.
An organization that reports phishing-resistant MFA compliance based on authenticator app deployment has a false representation in its compliance documentation. That is a different problem than having weak MFA. The distinction matters if the MFA is later bypassed in a credential phishing incident and the question becomes what the organization attested.
Where EO 14028 programs miss scope
The attestation is a legal document, not a questionnaire
Organizations that treat the CISA software attestation form as a compliance questionnaire — answering yes to each item based on a general belief that their security program is sound — are signing a legal attestation against specific technical claims. If an agency requests supporting artifacts and the organization cannot produce them, the attestation is not just incomplete. It is a potentially false statement made to a federal agency in connection with a government contract. The False Claims Act applies to false certifications in federal procurement. Most organizations that signed attestations in 2023 and 2024 did not have legal counsel review what specific SSDF practices they were affirming.
Container and cloud workload dependencies outside the SBOM scope
SBOMs are typically generated from application source code and package manifests. Container base images — the operating system layers that applications run on — have their own dependency graphs and their own vulnerability surface. A vendor who provides an SBOM for application dependencies and deploys that application on a container with an unpatched base image has an incomplete picture of what they shipped. Base image components are not always in the SBOM. They are in scope for the supply chain risk the order was designed to address.
Continuous attestation versus point-in-time certification
Software attestations are typically signed once at contract initiation or renewal. Software dependencies change continuously — new versions, new libraries, deprecated components replaced with alternatives. An attestation that was accurate at signing may not be accurate six months later if the software has been updated and the SBOM has not. The EO 14028 framework does not clearly specify how frequently attestations must be refreshed, which creates a gap: organizations treat the initial attestation as persistent, while agency security reviewers expect that ongoing software updates are reflected in current attestation status.
Incident response logging retention versus investigation reality
CISA's logging guidance specifies retention tiers based on log type. The minimum retention periods are designed around known incident investigation timelines. Sophisticated intrusions, however, have average dwell times that can exceed those minimums. An attacker who achieved initial access 13 months before detection at an organization retaining logs for 12 months has effectively erased their entry path from the log record. Organizations that retain logs at the minimum specified periods are compliant with the guidance and may still be unable to investigate the full scope of a long-dwell incident.
The evidence gap in practice
In Vulnox assessments of federal contractor environments, the average delay from logging deployment to discovery of an unencrypted log forwarding configuration was 78 days
Organizations deployed centralized logging to satisfy EO 14028 requirements, then moved on. The configuration — specifically, whether log transport was encrypted and authenticated — was not part of the initial deployment review and was not covered by subsequent compliance checks. The logging existed. The integrity of the logs could not be verified. An investigation relying on those logs for forensic evidence would have a chain-of-custody problem. (Vulnox assessment data, 2024-2025)
NTIA minimum elements for SBOMs: 7 required fields, including dependency relationships
The dependency relationship field is the one that separates a format-compliant SBOM from a functionally useful one. Automated SBOM generation tools produce all seven fields. Whether the dependency graph is complete — covering transitive dependencies to the extent known — depends on how the tool is configured and whether the build environment surfaces nested dependencies. Most default configurations do not.
OMB M-22-09 phishing-resistant MFA deadline: end of fiscal year 2024 for federal agency staff
The deadline applied to federal agencies, not directly to contractors. But agencies that implemented phishing-resistant MFA internally while their contractors used SMS-based MFA for systems shared between agency staff and contractor personnel have a boundary problem. The phishing-resistant perimeter stops at the agency boundary and resumes at risk on the contractor side.
The SBOM that increased risk by creating false confidence
Common belief
Producing and submitting an SBOM improves supply chain security by giving the federal agency visibility into what components are in the software.
What we found
In one assessed environment, an agency had reviewed the vendor's SBOM against the NVD and found no matches for current critical CVEs. The SBOM listed 94 components. A full transitive dependency scan of the same software identified 312 components. Three of the unlisted components had critical severity CVEs published in the 60 days prior to the review. The agency's SBOM review was thorough. The SBOM it reviewed was not.
An SBOM that covers only direct dependencies gives an agency the impression it has visibility into the software composition. When the agency uses that SBOM to assess whether the software has known vulnerabilities, it searches against the components listed. If the SBOM is incomplete — missing transitive dependencies where the actual vulnerability exists — the search returns clean results. The agency concludes the software is clear. The vulnerability is present. The SBOM did not reveal it, but it satisfied the procurement requirement and produced a documented review. The outcome is worse than no SBOM at all, because the review created a documented finding of no known vulnerabilities that contradicts reality.
Where EO 14028 enforcement is heading
By end of 2026, at least one federal software vendor will face a False Claims Act investigation specifically related to an inaccurate CISA software attestation, triggering agency-wide reviews of attestation supporting documentation across the federal software supply chain.
The CISA attestation form is a certification made in connection with a federal contract. The False Claims Act applies to false certifications in federal procurement. As agencies mature their vendor oversight processes and as post-incident investigations reveal gaps between attestation claims and actual development practices, the legal theory for FCA application is straightforward. The first action will be selected for its clarity as a precedent. The signal will be a DOJ announcement that names specific SSDF practices the vendor attested to and could not support with documentation.
Confidence: mediumNo DOJ FCA action specifically citing a CISA EO 14028 attestation by end of 2026Federal agencies will begin requiring SBOM updates on a defined refresh cycle — likely annual or tied to significant software version releases — within 18 months, eliminating the current practice of point-in-time SBOM submission at contract award.
The gap between static SBOMs and continuously updated software is well understood within CISA and OMB. The NTIA guidance anticipated ongoing SBOM maintenance. The enforcement mechanism to require it has not been formalized in acquisition regulations. As SBOM-related vulnerabilities appear in post-incident reviews — specifically cases where the SBOM on file did not reflect the component version actually deployed — the pressure to require refresh cycles will produce a regulatory response. The mechanism will be a FAR/DFARS clause update or an OMB memo modifying M-21-30 implementation guidance.
Confidence: highNo federal acquisition regulation update or OMB guidance requiring periodic SBOM refresh by mid-2027
What vendors say before the assessment — and what is underneath it
We have a SOC 2 Type II report. That covers our software security practices for the attestation.
Root cause:SOC 2 Type II evaluates whether an organization's controls related to security, availability, processing integrity, confidentiality, and privacy operated effectively over a review period. It does not evaluate compliance with SSDF practice identifiers. It does not verify that the organization produces SBOMs covering transitive dependencies. It does not assess whether development toolchains are configured to detect vulnerabilities in nested components. A SOC 2 report and a CISA attestation are answers to different questions. Using one as evidence for the other leaves the SSDF-specific requirements entirely unaddressed.
Our SIEM shows all logs are being collected. We are meeting the logging requirements.
Root cause:Log collection and log integrity are separate properties. A SIEM that shows logs being received confirms that the collection pipeline is running. It does not confirm that the transport is encrypted, that the logs cannot be tampered with between source and destination, that the retention period covers investigation requirements, or that the logs can be exported in structured formats within the timelines that post-incident investigations require. Organizations that conflate collection with compliance have a documented logging program and an undocumented evidence production capability.
We enabled MFA across all systems. The EO 14028 requirement is satisfied.
Root cause:EO 14028 and M-22-09 establish a specific standard: phishing-resistant MFA. The definition excludes SMS, voice call, and standard TOTP authenticator apps because all three are susceptible to real-time phishing relay attacks. The requirement is FIDO2/WebAuthn hardware keys or PIV credentials. Enabling any MFA satisfies the checkbox on a self-assessment form. It does not satisfy the defined standard. The distinction has operational consequences: a credential phishing attack that bypasses authenticator-app MFA — a documented, common technique — succeeds against a system that was reported as MFA-compliant.
What EO 14028 was actually trying to fix and why the compliance response missed it
EO 14028 was written in the aftermath of SolarWinds and Exchange Server. The SolarWinds incident demonstrated that a trusted software vendor could be compromised and used as a delivery mechanism for malware distributed through the normal software update process — and that federal agencies had no visibility into the software component chain that would have let them detect or respond to that compromise. The SBOM requirement, the attestation requirement, and the logging requirements are all responses to specific things that went wrong in that incident. The compliance response to the order has largely focused on producing the required documents rather than on closing the gaps the documents were designed to reveal. An SBOM that covers direct dependencies satisfies the procurement requirement. It would not have identified the SolarWinds build system compromise. The order was trying to create visibility into what is actually in federal software. Most compliance programs created documentation that the documentation requirement was met.
Counterargument
The counterargument is that perfect is the enemy of good — a procurement requirement for any SBOM is a meaningful improvement over no SBOM, and the infrastructure for transitive dependency coverage is still maturing. That is true for the first generation of compliance. It is not a reason to still be submitting incomplete SBOMs in 2026 when the tooling to produce complete ones is widely available and the NTIA guidance on depth has been published for three years.
One thing to do this week
Pull your most recent SBOM submission and run a transitive dependency scan against the same codebase using a tool that traverses the full dependency graph. Compare the component count. If the SBOM you submitted to an agency has fewer than half the components that a full scan produces, you have an attestation accuracy problem that predates your next contract renewal. Closing that gap takes a tooling configuration change, not a project. Do it before someone asks.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkNational Vulnerability Database Home
NVD vulnerability databaseOWASP Testing Methodologies
OWASP testing methodologies
Frequently Asked Questions
What does Executive Order 14028 actually require from software vendors selling to the federal government?
Section 4 of EO 14028 requires software vendors to provide a Software Bill of Materials, attest to compliance with NIST SP 800-218 secure software development practices, and make artifacts available for review when requested by federal agencies. The attestation requirement was formalized through CISA's self-attestation form, which requires vendors to affirm compliance with specific SSDF practices by practice identifier — not a generic statement of adherence. Vendors who have signed attestations without mapping their development practices to the specific SSDF requirements have a documentation exposure they may not have recognized.
What is an SBOM and what level of detail does EO 14028 compliance require?
A Software Bill of Materials is a machine-readable inventory of the components in a software product, including libraries, versions, and licensing. EO 14028 and subsequent NTIA guidance require SBOMs to include transitive dependencies — the libraries used by the libraries — not just top-level dependencies. Most SBOMs produced for initial compliance included only direct dependencies. An SBOM that lists a logging library but does not identify that library's own dependencies does not satisfy the depth requirement and will not identify vulnerabilities in nested components.
What logging requirements did EO 14028 create and what do regulators actually ask for?
EO 14028 Section 8 and subsequent OMB guidance require federal agencies to maintain logs sufficient to support investigation of security incidents. For federal agencies, this means centralized log collection with defined retention periods. When a post-incident review occurs, regulators and investigators request raw log data in machine-readable formats — JSON or CSV with full field sets — not dashboard screenshots or PDF summaries. Organizations that can produce visual reports but cannot export structured log data with timestamps, source identifiers, and event details face evidence production problems during investigations.
What is OMB M-22-09 and what does it require?
OMB Memorandum M-22-09, issued January 2022, directed federal agencies to implement zero trust architecture aligned with CISA's Zero Trust Maturity Model by the end of fiscal year 2024. It established specific requirements across five pillars: identity, devices, networks, applications and workloads, and data. For identity, it required phishing-resistant MFA for all staff — meaning hardware security keys or PIV credentials, not SMS or standard authenticator apps. Agencies and their contractors that implemented SMS-based MFA to satisfy the MFA requirement did not satisfy the phishing-resistant requirement M-22-09 specified.
Does EO 14028 apply to private sector companies that are not federal agencies?
EO 14028 applies directly to federal agencies. Its effect on private sector organizations comes through procurement — software vendors selling to federal agencies must meet the SBOM and attestation requirements as a condition of sale. The order does not directly regulate private companies that have no federal contracts, but its implementation through FISMA, FedRAMP, and agency acquisition policies creates obligations for any vendor in the federal software supply chain.
What is the NIST Secure Software Development Framework and how does it connect to EO 14028?
NIST SP 800-218, the Secure Software Development Framework, defines practices across four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. EO 14028 Section 4 directs NIST to publish guidance on secure software development, which SSDF fulfills. The CISA self-attestation form for software vendors references specific SSDF practice identifiers. A vendor who attests to SSDF compliance without documented evidence of each referenced practice has signed a statement they may not be able to support if an agency requests verification artifacts.
What evidence do federal investigators request after a security incident at an EO 14028-covered organization?
Based on documented post-incident review requests, investigators ask for: raw log exports with complete field sets in machine-readable format, network flow data covering the incident window, a timeline of responder actions including command history from incident response systems, SBOM data for affected software components, and access logs showing authentication events with device and location context. Organizations that have deployed logging but route it through unencrypted forwarders, or that store logs in formats requiring manual export, face production delays that complicate the investigation and raise questions about log integrity.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.