Background: EO 14028 and the Attestation Requirement
When President Biden signed Executive Order 14028 in May 2021, it set in motion a chain of guidance documents that fundamentally changed what it means to sell software to the U.S. government. The most operationally significant of these was OMB Memorandum M-22-18, which required software producers to complete a Secure Software Development Attestation Form — a self-certification that their products were built using the secure development practices defined in NIST's Secure Software Development Framework (SSDF).
The original attestation framework treated all software equally: any vendor selling a software product or service to a federal agency needed to complete the form. This created significant compliance overhead for vendors of low-risk tools and utilities while arguably not concentrating enough scrutiny on the highest-risk components in the federal software supply chain.
M-26-05, issued by the Office of Management and Budget in January 2026, addresses this imbalance directly.
What M-26-05 Actually Changes
The January 2026 memorandum does not revoke or replace EO 14028 or the SSDF requirements. Instead, it introduces a risk-based tiering system that determines the depth of attestation required based on the criticality of the software in question.
Tier 1: Critical Software
Software that operates with elevated privileges, has direct network access, or is embedded in operational technology (OT) or critical infrastructure contexts. For Tier 1 software, M-26-05 maintains the full attestation requirements of M-22-18 and adds a requirement for third-party assessment by an accredited assessor for contracts above a defined dollar threshold.
Tier 2: Standard Software
Productivity applications, data processing tools, and standard SaaS offerings that do not fall into the critical category. Tier 2 vendors continue to submit self-attestation forms but are no longer required to attest to every SSDF practice — only to a defined subset covering supply chain risk management, vulnerability disclosure, and component transparency.
Tier 3: Low-Risk Utilities
Open source tools, libraries provided as components (not as standalone products), and software with a documented, limited attack surface. Tier 3 products require a simplified declaration form with a reduced set of attested practices.
M-26-05 places the burden of tier self-classification on the software vendor, not the purchasing agency. Misclassification — intentional or not — is treated as a false statement in a federal procurement, with corresponding legal exposure under 18 U.S.C. § 1001.
SBOM Requirements Under the New Framework
One of the clearest outcomes of M-26-05 is the explicit codification of SBOM obligations by tier. Prior to this memo, SBOM requirements were implied by EO 14028 and various agency-level interpretations but were not uniformly enforced.
| Tier | SBOM Requirement | Format | Delivery |
|---|---|---|---|
| Tier 1 — Critical | Full SBOM, machine-readable, with VEX | SPDX 2.3+ or CycloneDX 1.5+ | Delivered at contract award, updated on each release |
| Tier 2 — Standard | SBOM available upon agency request | SPDX or CycloneDX (either version) | Provided within 72 hours of request |
| Tier 3 — Low Risk | Dependency manifest or equivalent | Any machine-parseable format | Available in source repository or on request |
For Tier 1 vendors, the VEX (Vulnerability Exploitability eXchange) requirement is new and significant. It means that alongside the SBOM, vendors must provide a machine-readable document stating which known vulnerabilities in their components are actually exploitable in the context of the delivered product. This directly addresses one of the loudest complaints about SBOM-based compliance: the noise problem created by hundreds of CVEs flagged for components that are included but never executed.
The Attestation Form Itself: What Is Being Replaced
The original M-22-18 attestation form was a single document covering 12 SSDF practice areas. M-26-05 replaces this with three tier-specific forms:
- Form AT-1 — Full attestation for Tier 1 critical software (17 practice areas, third-party verification pathway)
- Form AT-2 — Standard attestation for Tier 2 (8 practice areas, self-attested)
- Form AT-3 — Simplified declaration for Tier 3 (3 practice areas, declaration of intent)
All three forms require explicit attestation of supply chain risk management practices, including the ability to identify and remediate vulnerable components within a defined timeframe. For Tier 1, that timeframe is 72 hours for critical severity (CVSS ≥ 9.0) and 15 days for high severity.
Existing vendors with current M-22-18 attestations have until July 1, 2026 to submit updated attestations under the M-26-05 framework. New contracts entered after January 15, 2026 must use the new tiered forms immediately.
Impact on Commercial Software Vendors
The practical impact of M-26-05 depends entirely on where a vendor's products fall in the tiering system. For most commercial SaaS vendors selling productivity tools or analytics platforms to federal agencies, the new framework actually reduces compliance burden — Tier 2 self-attestation with a subset of SSDF practices is less onerous than the original M-22-18 full attestation.
For vendors of infrastructure software, security tools, network management platforms, and anything touching critical systems, Tier 1 classification means increased obligations: third-party assessment pathways, mandatory SBOM with VEX, and tighter vulnerability response SLAs.
The group most affected is vendors who previously self-classified as low-risk but whose software the new CISA critical software definition places in Tier 1. CISA updated its critical software definition in November 2025 to explicitly include software that "manages or controls access to data, systems, or networks used in critical infrastructure sectors," which is broader than many vendors anticipated.
What You Need to Do Now
Regardless of tier, the first action is classification. Vendors need to review their product portfolio against the M-26-05 tier definitions and CISA's updated critical software guidance before submitting any new attestation forms. Getting this wrong has legal consequences that go beyond losing a contract.
- Audit your product list against CISA's critical software definition (updated November 2025)
- Determine the applicable tier for each product sold to federal customers
- If Tier 1: begin third-party assessment procurement and implement VEX generation in your release pipeline
- If Tier 2: confirm your SBOM generation capability and 72-hour delivery window
- Submit updated attestation forms for existing contracts before July 1, 2026
For teams without an established SBOM program, M-26-05 makes the business case straightforward: every tier now requires some form of component transparency documentation. Building that capability once and maintaining it is more efficient than scrambling to produce it per-request.
Generate Attestation-Ready SBOMs and VEX Documents
Fossity generates SPDX and CycloneDX SBOMs from your repositories and build artifacts, and produces VEX documents that map known CVEs to actual exploitability in your codebase. Purpose-built for teams that need to satisfy federal attestation requirements without building custom tooling.
Get Compliant with Fossity →The Broader Picture: Federal Policy Trajectory
M-26-05 is one data point in a longer policy trajectory. The underlying direction — more component transparency, faster vulnerability response, and greater accountability for the software supply chain — has remained consistent across administrations and is reflected in parallel requirements from FDA, the EU Cyber Resilience Act, and DORA.
Vendors who build their SBOM and secure development programs to the highest common denominator (Tier 1 / EO 14028 full compliance) will find themselves well-positioned as additional jurisdictions move in the same direction. Compliance built to the minimum required for one regulation rarely satisfies another.