Executive Order 14028 and Its Code Compliance Mandates

Executive Order 14028, signed by President Biden on May 12, 2021, restructured the federal government's approach to software security by converting previously voluntary security guidance into enforceable procurement conditions. The order directly affects every software vendor, contractor, and developer whose products touch federal information systems. This page documents the order's definition and scope, its structural mechanics, the compliance obligations it generates for software development teams, and the tradeoffs organizations face when implementing its mandates.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps
• Reference Table or Matrix

Definition and Scope

Executive Order 14028, titled Improving the Nation's Cybersecurity (Federal Register Vol. 86, No. 93), mandates that federal agencies modernize their cybersecurity posture across three primary domains: software supply chain security, zero trust architecture adoption, and endpoint detection capabilities. For software developers and code compliance professionals, the most operationally significant provisions appear in Section 4, which directs the National Institute of Standards and Technology (NIST) to publish guidelines defining what constitutes secure software development practices for federal procurement.

The order's geographic and institutional scope is broad. Any entity selling software to a civilian federal agency — including commercial software vendors, open-source contributors whose components are embedded in federal systems, and managed service providers — falls within its procurement-conditioned reach. The Department of Defense has parallel obligations under related directives, while civilian agencies are governed by Office of Management and Budget (OMB) memoranda issued under the order's authority, notably OMB M-22-18, which established self-attestation and Software Bill of Materials (SBOM) requirements.

Understanding EO 14028 in context requires situating it within the broader regulatory context for code compliance that governs federal software procurement, alongside frameworks such as NIST SP 800-53 and FedRAMP.

Core Mechanics or Structure

The order operates through a delegation chain rather than direct enforcement. EO 14028 directs agencies, which direct OMB and NIST, which produce binding guidance and standards, which then flow into Federal Acquisition Regulation (FAR) modifications and agency-level contract language. The result is that code compliance obligations reach developers through contractual mechanisms rather than through direct statutory command.

The structural pillars most relevant to software code compliance are:

Section 4 — Software Supply Chain Security. NIST was directed to publish guidance within 60 days addressing criteria for evaluating software security. NIST responded with NIST SP 800-218 (Secure Software Development Framework, SSDF), which organizes requirements into four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Each practice group contains specific tasks and implementation examples that map directly to code-level activities such as static analysis, dependency management, and vulnerability disclosure.

OMB M-22-18 Attestation Requirements. Agencies must obtain self-attestations from software producers confirming conformance with NIST SSDF. The attestation form references specific SSDF practice areas and requires an authorized official — typically a C-suite signatory — to affirm that the development pipeline meets defined standards. Third-party assessments are required for critical software, as defined by CISA's critical software criteria.

Software Bill of Materials (SBOM). Section 4(e) of EO 14028 explicitly requires that software sold to federal agencies include a machine-readable SBOM. NTIA's Minimum Elements for a Software Bill of Materials defines the required data fields: supplier name, component name, version, unique identifiers, dependency relationships, author of SBOM data, and timestamp. The SBOM requirement is detailed further at software-bill-of-materials-compliance.

Causal Relationships or Drivers

EO 14028 was issued in direct response to two high-profile supply chain compromises that demonstrated systemic failure in federal software vetting. The SolarWinds intrusion, disclosed in December 2020, involved malicious code injected into a signed software update affecting approximately 18,000 organizations, including multiple federal agencies (CISA Alert AA20-352A). The Microsoft Exchange Server vulnerabilities exploited in early 2021 further illustrated that perimeter-focused security models failed to account for software-layer attack vectors.

These incidents revealed a structural gap: federal agencies had no standardized mechanism to verify that commercial software they procured had been developed with adequate security controls. Existing frameworks such as FISMA focused on system-level controls after deployment rather than on the development process that produced the software. EO 14028 shifted the compliance point upstream — into the SDLC itself — making SDLC compliance integration a procurement requirement rather than an optional engineering practice.

Classification Boundaries

EO 14028 and its implementing guidance distinguish between software categories that trigger different obligation levels:

Critical Software. CISA defines critical software as software that, if compromised, could have severe impacts on safety, security, or continuity of operations. This category triggers mandatory third-party assessment rather than self-attestation alone. Examples include operating systems, security software, identity and access management tools, and network management products.

Operational Technology (OT) and IoT. EO 14028's software security requirements extend in principle to firmware and embedded systems, though NIST's sector-specific guidance distinguishes OT environments. Compliance mapping for these environments intersects with frameworks addressed at iot-firmware-code-compliance.

Open-Source Components. OMB M-22-18 clarifies that SBOM requirements apply to open-source components embedded in commercial products. A vendor cannot exclude open-source dependencies from the attestation scope.

SaaS vs. On-Premises Software. The attestation framework applies regardless of deployment model. A SaaS vendor serving a federal agency must attest to SSDF conformance for its production codebase, not merely its infrastructure controls.

Tradeoffs and Tensions

Attestation as paper compliance risk. The self-attestation model established by OMB M-22-18 depends on organizational honesty. A C-suite signatory affirming SSDF conformance without verified internal audit creates liability exposure if a subsequent breach reveals non-conformance, but does not guarantee actual code security. This tension between administrative efficiency and genuine assurance is a known limitation acknowledged in the OMB guidance itself.

SBOM completeness versus competitive sensitivity. Full dependency disclosure via SBOM exposes proprietary architectural decisions. Vendors selling to both federal and commercial markets face pressure to limit SBOM granularity, but NTIA minimum elements leave limited room for omission. The tension between transparency and intellectual property protection remains unresolved in current federal guidance.

Speed versus security in the SDLC. Implementing NIST SSDF practices — particularly the PW (Produce Well-Secured Software) group, which includes threat modeling, secure design reviews, and code analysis — adds measurable time to development cycles. Organizations adopting devsecops-code-compliance-automation tooling report reduced friction, but the upfront investment in pipeline redesign is non-trivial for mid-size vendors.

Scope creep through contract language. Because EO 14028 obligations flow through FAR modifications and agency-specific clauses, two agencies purchasing the same software product may impose materially different attestation formats, SBOM schemas, or audit rights. Vendors serving 5 or more federal agencies may face conflicting implementation requirements with no central harmonization authority currently resolving them.

Common Misconceptions

Misconception: EO 14028 applies only to federal agencies, not vendors.
The order directs agencies, but its operative compliance obligations are contractual conditions placed on software producers. A vendor that does not sell to the federal government is not directly bound, but any vendor in the federal supply chain — including subcontractors two or three tiers removed — may face pass-through requirements from a prime contractor bound by federal clauses.

Misconception: SBOM submission alone satisfies Section 4 requirements.
SBOM is one element of a multi-part compliance framework. OMB M-22-18 requires SSDF self-attestation as a separate and independent obligation. Submitting an SBOM without a signed attestation does not fulfill the order's requirements.

Misconception: NIST SSDF is a checklist that can be completed once.
The SSDF is a continuous practice framework, not a one-time certification. NIST SP 800-218 explicitly states that organizations should integrate SSDF practices into ongoing development workflows. A point-in-time conformance assessment does not substitute for sustained operational compliance, which requires the kind of ongoing monitoring described at code-compliance-audit-process.

Misconception: EO 14028 requirements are finalized and static.
OMB and CISA have issued iterative guidance documents since 2021, and the FAR Council published proposed rule changes to embed SBOM and attestation requirements into contract language. The regulatory framework continues to evolve; the homepage of this reference maintains current framework tracking.

Checklist or Steps

The following sequence reflects the structural compliance process implied by EO 14028's implementing documents — not professional advice:

1. Determine applicability. Confirm whether the organization's software products are sold to, or embedded in products sold to, U.S. federal civilian agencies subject to FAR.
2. Identify software classification. Apply CISA's critical software criteria to determine whether self-attestation or third-party assessment is required.
3. Map development practices to NIST SSDF. Review the four practice groups (PO, PS, PW, RV) in NIST SP 800-218 and document how existing development activities correspond to each task.
4. Conduct gap analysis. Identify SSDF tasks not currently addressed by the development pipeline — common gaps include formal threat modeling (PW.1), code integrity verification (PS.2), and vulnerability disclosure policy (RV.1).
5. Generate SBOM artifacts. Implement tooling capable of producing SBOMs conforming to NTIA minimum elements for each software release. Supported formats include SPDX and CycloneDX.
6. Draft attestation documentation. Prepare the OMB-specified attestation form with evidence mapping to SSDF practices. Identify the authorized organizational signatory.
7. Submit to procuring agency. Deliver attestation and SBOM per the specific agency's contract requirements, noting that format and submission portal vary by agency.
8. Establish continuous monitoring. Implement processes to detect new vulnerabilities in attested components (SSDF RV.1) and re-attest upon material changes to the software.

Reference Table or Matrix

Sources: Federal Register Vol. 86 No. 93; NIST SP 800-218; OMB M-22-18

References

• Executive Order 14028 — Federal Register Vol. 86, No. 93
• NIST SP 800-218: Secure Software Development Framework (SSDF)
• OMB Memorandum M-22-18: Enhancing the Security of the Software Supply Chain
• NTIA: Minimum Elements for a Software Bill of Materials
• CISA: Definition of Critical Software Under EO 14028
• CISA Alert AA20-352A: SolarWinds Supply Chain Compromise
• NIST SP 800-207: Zero Trust Architecture
• OMB Memorandum M-21-31: Improving the Federal Government's Investigative and Remediation Capabilities