EO 14028: what US federal procurement now requires from software vendors
Executive Order 14028 made software supply chain security a federal procurement requirement. If any of your customers are US federal agencies — or contractors who supply them — you need machine-readable SBOMs, NIST SSDF attestation, and a published vulnerability disclosure process. Here is what that means in practice.
Does EO 14028 apply to you?
EO 14028 created binding requirements on federal agencies for software they procure. Those requirements flow down to you as a vendor. If any of the following apply, federal customers are already asking for EO 14028 compliance evidence:
- You sell software, SaaS, or firmware to US federal agencies covered by FISMA
- You sell to a prime contractor who incorporates your software into a federal delivery
- Your software is used in federal critical infrastructure operations
- You provide cloud services consumed by federal agencies under a FedRAMP or agency-specific ATO
OMB guidance (M-22-18, M-23-16) makes SBOM delivery and SSDF attestation a contractual requirement for software procured by federal agencies. Without compliance, you cannot close or renew federal contracts.
EO 14028 timeline
President Biden signed the Executive Order on Improving the Nation's Cybersecurity, directing NIST, CISA, and OMB to develop binding guidance for federal software procurement.
NIST published the Secure Software Development Framework establishing the practices vendors must attest to. NTIA published minimum SBOM elements. NIST SP 800-161r1 updated supply chain risk management guidance.
OMB memorandum M-22-18 required agencies to collect SSDF attestations from all software vendors within 270 days (critical software) or 365 days (all other software). Self-attestation or third-party assessment required.
Federal agencies are incorporating SBOM delivery, VDP requirements, and SSDF attestation into contract language. CISA's Secure by Demand guidance sets expectations for federal software procurement standards.
What federal customers need from you
OMB guidance and agency contract requirements map to four concrete deliverables. Each has specific format and delivery expectations:
Machine-readable SBOM per product
Federal agencies require SBOMs in CycloneDX or SPDX format. At minimum, each SBOM must include: supplier name, component name, version of the component, other unique identifiers (purl, CPE), dependency relationship, author of the SBOM data, and timestamp. Agencies may require SBOMs for each release or on a defined cadence.
EO 14028 §4(e), NTIA SBOM minimum elements, OMB M-22-18
NIST SSDF attestation (self or third-party)
OMB M-22-18 requires a self-attestation confirming your software development follows NIST SP 800-218 (SSDF) practices. The attestation must cover: secure design, secure development environments, producing well-secured software, and responding to vulnerabilities. Critical software (internet-accessible, privileged access, or security-related functions) requires third-party assessment evidence.
OMB M-22-18, OMB M-23-16, NIST SP 800-218
Vulnerability disclosure policy (VDP)
EO 14028 and CISA guidance require software in the federal supply chain to have a published VDP covering: how to report a vulnerability, what information to include, your commitment to acknowledge and triage reports, and expected response timelines. Machine-readable advisories in CSAF format and VEX documents are the standard for transparent, automatable vulnerability disclosure.
EO 14028 §4(e)(viii), CISA VDP guidance, ISO 29147
Controlled SBOM delivery per contract
Agencies often require SBOMs to be delivered per contract rather than published publicly — especially for sensitive or classified environments. You need a mechanism to provide SBOMs to a specific agency under controlled access without exposing component data to competitors or adversaries. Scoped, token-gated access that expires or can be revoked is the practical answer.
OMB M-22-18 Section 3, agency-specific contract clauses
What EO 14028 does not require
EO 14028 is a directive to federal agencies, not a regulation directly binding on vendors. Compliance is enforced through contract terms, not statutory penalties on vendors. That said:
- No mandatory public SBOM publication — SBOMs can be delivered directly to the agency under controlled access. Public availability is one option but not the only one.
- No mandated certification body — SSDF attestation is self-attestation for most software. Third-party assessment is required only for critical software meeting CISA's criteria.
- No prescribed toolchain — the requirement is for SBOM content (minimum elements) and format (CycloneDX or SPDX), not for how you generate it.
- No direct fines — failure to comply results in contract non-award, contract termination, or removal from the federal approved vendor list, not monetary penalties.
How Security2Center maps to EO 14028 obligations
Security2Center gives federal customers a single, self-serve portal to access the SBOM and supply chain security documentation EO 14028 requires. Here is how each feature maps:
3 months free. No credit card. Full access.
Start your free trialFrequently asked questions
What is Executive Order 14028?
EO 14028, signed in May 2021, directed US federal agencies to modernize cybersecurity practices and created mandatory requirements for software sold into the federal government. Key requirements include SBOM delivery, NIST SSDF compliance attestation, vulnerability disclosure policies, and enhanced incident reporting. The order's implementation is driven by OMB memoranda (M-22-18, M-23-16) and CISA guidance.
Does EO 14028 apply to my SaaS product?
Yes, if federal agencies use your SaaS. OMB M-22-18 covers "software" broadly, including SaaS, cloud-hosted applications, and software-as-a-service platforms with federal agency customers. SSDF attestation and vulnerability disclosure requirements apply regardless of deployment model. SBOM requirements may cover the software components your service depends on.
What is the difference between CycloneDX and SPDX?
Both are NTIA-accepted SBOM formats. CycloneDX (maintained by OWASP) is optimized for security use cases — it includes vulnerability data, license compliance information, and supports VEX. SPDX (maintained by the Linux Foundation) originated in the open source licensing space and is the ISO standard (ISO/IEC 5962:2021). Most federal agencies accept either format; CycloneDX is increasingly preferred for security-focused use cases.
What does SSDF attestation require in practice?
You complete a self-attestation form confirming your software development process follows NIST SP 800-218 practices across four categories: preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. For critical software, agencies may require artifacts — pen test results, code review records, CI/CD pipeline documentation — as supporting evidence. Security2Center lets you publish these as gated documents accessible only to authorized federal customers.
How does EO 14028 relate to the EU CRA?
Both require SBOMs, vulnerability disclosure, and software supply chain transparency, but they are independent frameworks with different enforcement mechanisms. The CRA is EU law with direct fines on manufacturers. EO 14028 is enforced through US federal procurement contracts. The required SBOM formats (CycloneDX, SPDX) are identical — a single SBOM infrastructure satisfies both. Many vendors selling globally face both simultaneously.
Do I need to publish my SBOM publicly?
Not necessarily. OMB guidance allows agencies to receive SBOMs through controlled delivery mechanisms rather than public publication. If you have customers in both the public sector and commercial markets, public SBOMs may expose competitive component information. Per-contract access control — where each agency or contractor gets a scoped, time-limited access link — is the practical solution for sensitive deployments.