OMB M-26-05 Ended the Federal Software Attestation Mandate. Here's What Vendors Still Face

On 23 January 2026, OMB Memorandum M-26-05 rescinded M-22-18 and M-23-16, the two memos that required federal agencies to collect a secure software development attestation from every producer of software they use. On 6 March, the FAR Council withdrew FAR Case 2023-002, the rule that would have written that requirement into contracts. Since then, attestation has been an option each agency can choose, not a government-wide condition of sale. Many vendor trust pages, questionnaire answers and proposal templates still say otherwise.

This post is for software vendors that sell to US federal agencies, and for the security and compliance teams who answer their questionnaires. It sets out what changed between 2025 and 2026, what M-26-05 still asks agencies to do, which new requirements are coming instead, and a script that finds stale references in your own documents.

The short answer

As of 16 October 2026, no government-wide rule requires software producers to give federal agencies a secure software development attestation. M-26-05 rescinded M-22-18 and M-23-16, EO 14306 struck the EO 14144 provisions that would have required machine-readable attestations and supporting artifacts to be filed with CISA, and FAR Case 2023-002 was withdrawn. Agencies must still keep a complete software and hardware inventory and set their own risk-based assurance requirements. They may still use the attestation form, and they may require an SBOM on request. The next government-wide contractor requirements on the way are about post-quantum cryptography and vulnerability disclosure, under EO 14412.

What changed, in order

The withdrawal is recorded in the FAR Council's entry in the Unified Agenda published on 14 August 2026. Its abstract says the rule "is closed because it was intended to implement" OMB direction that M-26-05 rescinded.

What M-26-05 says

The memo is two pages. It says each agency head "is ultimately responsible" for the security of software and hardware on the agency's network, and that there's no one-size-fits-all method. It describes M-22-18 as imposing "unproven and burdensome software accounting processes" and says it neglected hardware.

What it keeps is as important as what it removes:

• Inventory. Agencies "shall continue to maintain a complete inventory of software and hardware".
• Assurance policies. Agencies must develop software and hardware assurance policies and processes that match their own risk determinations and mission needs.
• The attestation form, optionally. Agencies "may choose to use" the government-wide resources developed under M-22-18, including the Secure Software Development Attestation Form.
• SBOMs on request. Agencies may adopt contract terms requiring a producer to provide a current SBOM on request. A footnote adds that for a cloud platform, the SBOM should cover the runtime production environment.

It points agencies to NIST SP 800-218, CISA's draft 2025 Minimum Elements for an SBOM, and CISA's Hardware Bill of Materials framework.

What it means for vendors

The practical change is from one form to many questions. Under M-22-18, a producer signed one attestation, and agencies collected it. Under M-26-05, each agency decides what evidence it wants, based on its own risk assessment. Some will keep asking for the attestation form because it's familiar. Others will ask for SBOMs, SSDF-mapped questionnaires, or hardware provenance, which the old memo didn't cover.

Three things follow:

1. Don't tell a federal buyer that attestation is legally required. It was true in 2024. It hasn't been true since January.
2. Keep the attestation form ready anyway. It's still the cheapest answer for an agency that asks for it, and it maps to the SSDF practices you should be following regardless.
3. Be ready to produce an SBOM quickly. "On request" clauses put the timing in the agency's hands. For SaaS, the footnote means an SBOM of what actually runs in production, not just the code you build.

M-26-05 doesn't revoke EO 14028, and EO 14306 amended EO 14144 and EO 13694 rather than EO 14028, so the policy direction toward secure development practices remains. What's gone is the government-wide mechanism for proving it.

What's coming instead

EO 14412, signed on 22 June 2026, sets the next contractor obligations, and they're about cryptography rather than development process:

• FIPS and post-quantum cryptography in contracts. Within 180 days, by about 19 December 2026, the FAR Council must publish a proposed rule requiring covered contractors to comply with NIST's FIPS, including the post-quantum standards, by 31 December 2030.
• Vulnerability disclosure programs. Within 270 days, by about 19 March 2027, a proposed FAR rule must require covered contractors to run vulnerability disclosure policies that accept reports of cryptographic weaknesses, including missing encryption and non-FIPS algorithms.
• A cryptographic bill of materials. Within the same 270 days, CISA and NIST must publish minimum elements for a CBOM, designed for automated assessment of the cryptography in hardware and software. Our explainer on what a cryptographic bill of materials is covers the format.

OMB's implementing memo, M-26-15 of 24 June 2026, gives agencies 120 days to submit post-quantum migration plans, which lands on 22 October 2026. It tells agencies to make sure requirements for products in CISA's post-quantum product categories include PQC integration, and names SBOM analysis as one input to an automated cryptographic inventory. Expect cryptography questions in federal questionnaires well before the FAR rules are final.

Find stale references in your documents

This script scans a folder of trust-page copy, questionnaire answers, proposal templates or docs, and flags lines that cite policies whose status has changed: M-22-18, M-23-16, FAR Case 2023-002, the RSAA filing requirement, wording that calls attestation mandatory, BOD 22-01, and the SSDF 1.2 draft cited as final. Each finding names the change and its source. It uses only the Python standard library.

#!/usr/bin/env python3
"""Find references to rescinded or withdrawn US federal software-security policy.

Scans text, Markdown, HTML and similar files (trust pages, security
questionnaire answers, proposal boilerplate, docs) and reports each line
that cites a policy whose status changed. Standard library only.

  python3 stale_federal_refs.py DIR [DIR ...]
"""
import os, re, sys

# pattern, status as of 16 Oct 2026, primary source
RULES = [
    (r"\bM-22-18\b", "rescinded 23 Jan 2026 by OMB M-26-05", "OMB M-26-05"),
    (r"\bM-23-16\b", "rescinded 23 Jan 2026 by OMB M-26-05", "OMB M-26-05"),
    (r"FAR Case 2023-002|9000-AO49", "withdrawn 6 Mar 2026 (Unified Agenda, 14 Aug 2026)", "91 FR, 2026-16612"),
    (r"\bRSAA\b|Repository for Software Attestations? and Artifacts",
     "EO 14144 sec. 2(b) RSAA submission requirement struck by EO 14306 (6 Jun 2025)", "EO 14306 sec. 1(a)"),
    (r"(must|required to|mandatory|requires? (all )?(software )?(producers|vendors|suppliers) to)[^.\n]{0,80}"
     r"(attestation|attest)|(attestation|attest)[^.\n]{0,60}(is|are) (required|mandatory)",
     "federal secure software attestation is optional per agency since M-26-05", "OMB M-26-05"),
    (r"\bBOD 22-01\b", "revoked by CISA on 10 Jun 2026", "CISA"),
    (r"SP 800-218 ?(Rev(ision)?\.? ?1|r1)|SSDF (v|version )?1\.2",
     "still a draft (initial public draft 17 Dec 2025); check before citing as final", "NIST CSRC"),
]
EXTS = {".md", ".mdx", ".txt", ".html", ".htm", ".rst", ".adoc", ".csv", ".json", ".yaml", ".yml"}
SKIP = {".git", "node_modules", "dist", "build", ".venv"}


def scan(root):
    hits = 0
    for dirpath, dirs, files in os.walk(root):
        dirs[:] = [d for d in dirs if d not in SKIP]
        for f in sorted(files):
            if os.path.splitext(f)[1].lower() not in EXTS:
                continue
            path = os.path.join(dirpath, f)
            try:
                lines = open(path, errors="replace").read().splitlines()
            except OSError:
                continue
            for n, line in enumerate(lines, 1):
                seen = set()
                for pattern, status, source in RULES:
                    m = re.search(pattern, line, re.I)
                    if m and status not in seen:
                        seen.add(status)
                        hits += 1
                        excerpt = line.strip()
                        if len(excerpt) > 90:
                            start = max(0, m.start() - 30)
                            excerpt = ("..." if start else "") + line[start:start + 90].strip() + "..."
                        print(f"{os.path.relpath(path, root)}:{n}: {status} [{source}]")
                        print(f"    {excerpt}")
    return hits


if __name__ == "__main__":
    total = sum(scan(d) for d in (sys.argv[1:] or ["."]))
    print(f"\n{total} reference(s) to review." if total else "No stale references found.")
    sys.exit(1 if total else 0)

We ran it on 16 October against three sample documents, a trust page, a questionnaire export and a proposal snippet, written the way such documents often read:

$ python3 stale_federal_refs.py docs
sales/proposal.html:1: withdrawn 6 Mar 2026 (Unified Agenda, 14 Aug 2026) [91 FR, 2026-16612]
    <p>The forthcoming FAR rule (FAR Case 2023-002) will make attestation mandatory for all fe...
sales/questionnaire.csv:2: still a draft (initial public draft 17 Dec 2025); check before citing as final [NIST CSRC]
    ...00-218 v1.1) and are tracking SSDF version 1.2....
sales/questionnaire.csv:3: revoked by CISA on 10 Jun 2026 [CISA]
    13,Do you track KEV?,Yes. We remediate KEV entries within the BOD 22-01 timelines.
trust/federal.md:3: rescinded 23 Jan 2026 by OMB M-26-05 [OMB M-26-05]
    Under OMB M-22-18 and M-23-16, federal agencies require software producers to submit a
trust/federal.md:4: EO 14144 sec. 2(b) RSAA submission requirement struck by EO 14306 (6 Jun 2025) [EO 14306 sec. 1(a)]
    Secure Software Development Attestation. Our attestation is on file in CISA's RSAA.

5 reference(s) to review.

It matches single lines only, so a sentence split across lines can slip through. Treat a clean run as a first pass and have someone read the federal sections end to end.

What to do

1. Update your trust page and boilerplate. Replace "required under M-22-18" with what's true now: you follow the SSDF, can provide the attestation form, and can provide an SBOM on request.
2. Map your practices to SSDF anyway. Agencies writing their own assurance requirements will reach for SP 800-218, and version 1.2 is in draft.
3. Make SBOM delivery routine, including a runtime SBOM for hosted services.
4. Start a cryptographic inventory. Know which algorithms your products use, where they come from, and which ones the post-quantum FIPS will replace.
5. Publish a vulnerability disclosure policy that explicitly accepts cryptographic findings, before a FAR clause requires it.

The fair view

There's a reasonable case for M-26-05. A self-attestation signed once said little about whether a producer actually followed the practices, and the planned RSAA filings and artifact reviews would have cost vendors and CISA a lot to administer. Letting agencies set evidence requirements by risk is closer to how mature buyers already work.

But it moves cost rather than removing it. Vendors that sold to many agencies had one form to complete. Now they may face as many variations as they have customers, and a smaller vendor has less leverage to push back on a long questionnaire. The SBOM-on-request clause and the coming post-quantum rules point the same way: federal buyers will want evidence they can check by machine, not signatures. Vendors that can produce inventories of their software and their cryptography on demand will spend less time on all of it.