Executive Order 14028 was signed in May 2021, but the practical work of operationalizing it stretched across five years and three administrations. Now that the dust has settled on the initial push, it is worth taking inventory. What requirements actually ship in federal procurement contracts? Which expectations quietly died? And where did the market go in directions nobody anticipated?
This is a field report, not a policy essay. I have spent the past two years working with agencies and vendors trying to make attestations, SBOMs, and secure development paperwork actually mean something. The gap between the memo and the pipeline is still wider than it should be.
What requirements are actually showing up in federal contracts?
The clearest winners are the M-22-18 and M-23-16 self-attestations. By early 2026, nearly every software vendor selling to federal civilian agencies has submitted at least one attestation through the CISA Repository for Software Attestation and Artifacts. The form itself is short, which was deliberate, but the supporting artifacts behind it are where the real work sits.
SBOMs are requested in roughly 70 to 80 percent of procurement packages I have seen, but the enforcement is uneven. Some agencies treat them as required deliverables. Others treat them as nice-to-have. What has shipped is the expectation that a vendor can produce an SBOM on demand, in either CycloneDX or SPDX, for any shipped artifact. Vendors who cannot are quietly being filtered out during technical evaluation.
The secure software development framework (SSDF) practices from NIST SP 800-218 have become the common reference language. Whether or not an agency formally audits against them, RFPs consistently ask vendors to map their development practices to SSDF tasks. That mapping is now a baseline, not a differentiator.
Which pieces of the order stalled or got watered down?
The vulnerability disclosure program requirement has been the most disappointing. While many vendors now publish a security.txt or a VDP page, the quality varies wildly. Coordinated disclosure still breaks down in practice, especially when the reporter is external and the vendor has no dedicated PSIRT. The order nudged the culture, but it did not mandate the staffing or processes needed.
Zero trust architecture deadlines slid repeatedly. The original 2024 target for agency ZTA maturity was ambitious given appropriations reality. By 2026, most CFO Act agencies have deployed identity-centric controls and microsegmentation in parts of their enterprise, but the end-to-end application of Kindervag-style zero trust remains aspirational in legacy estates.
The software bill of materials quality requirements also softened. The 2021 memos implied that minimum SBOM elements from CISA would harden into normative requirements. Instead, CISA has published guidance, revised it, and continued iterating. That is healthy for a young field, but it means vendors have had to shoot at a moving target.
Where did the market move faster than the policy?
Reachability analysis is the clearest example. Nothing in EO 14028 directs vendors or agencies to distinguish reachable from unreachable vulnerabilities in their dependencies. But the operational math is unavoidable: a typical Node or Python application has thousands of CVEs in its transitive dependencies, and only a small fraction are actually callable from the application entry points. Procurement teams figured this out faster than regulators did, and now RFP questionnaires increasingly ask about how vendors prioritize which CVEs to fix.
VEX adoption also outpaced the policy. The executive order did not mention VEX in any serious way, yet OpenVEX and CycloneDX VEX are now the primary way vendors communicate "we know about CVE-X and here is why it does not affect you." Agencies started asking for VEX alongside SBOMs because the unfiltered SBOM was creating far more noise than signal.
Finally, the container and build provenance story evolved beyond what the order anticipated. SLSA levels, Sigstore, and in-toto attestations are the practical substrate that turned "attestation" from a PDF ritual into a verifiable chain of signed artifacts.
How are agencies actually consuming SBOMs in 2026?
The honest answer is that most agencies are not fully operationalizing SBOMs yet. Collection is solved. Storage is mostly solved. Analysis is still early.
The agencies doing this well have centralized ingestion pipelines that normalize CycloneDX and SPDX into a common graph, correlate components against vulnerability feeds, and apply VEX to suppress known non-exploitable issues. The agencies doing this poorly have thousands of SBOM files sitting in S3 buckets that nobody has queried since ingestion.
The gap between these two groups is almost entirely about tooling and staffing, not policy. The order laid the legal and procurement groundwork. Building out the analyst workflows and SBOM-aware SIEM integrations is the part that takes longer and has no deadline attached.
What should vendors and agencies focus on next?
For vendors, the priority is making your SBOM pipeline boring. SBOM generation should be a post-build step in every pipeline, signed with Sigstore, published to your customers automatically. If you are still generating SBOMs manually for compliance submissions, you are carrying technical debt that will compound.
For agencies, the priority is turning SBOMs into queries. Store them in a graph, correlate them with your asset inventory, and build standing reports that answer questions like "which of our systems run the affected version of library X" in seconds rather than weeks. The SolarWinds response took months partly because nobody could answer that question.
For both sides, VEX is the force multiplier. Without VEX, SBOM analysis drowns in false positives. With VEX, you can actually operationalize the data you have been collecting. The vendors who learn to publish high-quality VEX documents will win procurement battles against vendors who publish only SBOMs.
What are the unintended consequences of the order so far?
A market for SBOM compliance theater emerged. Some vendors produce SBOMs that technically meet minimum elements but omit transitive depth, skip identifier quality, and ignore license fields. These SBOMs pass the intake check at many agencies but provide almost no operational value. The order did not specify quality bars, so the gray area is wide.
Small vendors have felt the pressure unevenly. Federal procurement was already heavy for small businesses, and the SBOM plus attestation stack added real cost. Some vendors exited federal work rather than absorb the compliance overhead. Others leaned into it and used EO 14028 readiness as a differentiator. The policy intent was not to thin the vendor pool, but that has been part of the outcome.
Open-source project maintainers have been caught in an awkward position. Federal contractors use open-source components and need SBOM-ready supply chains, but the maintainers themselves receive no compensation for the compliance burden this creates. Expect this tension to show up in future policy, likely through funding mechanisms for critical open-source infrastructure.
How Safeguard.sh Helps
How Safeguard.sh Helps
Safeguard.sh was built for exactly the gap EO 14028 exposed between paperwork and operational security. Our reachability engine cuts SBOM-derived vulnerability noise by 60 to 80 percent by tracing which CVEs are actually callable from your application entry points, so compliance teams and engineers focus on the same short list. Griffin AI ingests your CycloneDX and SPDX SBOMs, applies VEX intelligently, and maps findings to SSDF tasks and EO 14028 attestation requirements in one pass. With 100-level transitive dependency depth, integrated TPRM for your upstream vendors, and container self-healing that regenerates images against fresh base layers, Safeguard.sh closes the loop between attestation and remediation that most agencies and vendors still handle in spreadsheets.