In EO 14028, critical software means software that performs functions critical to trust, such as elevated system privileges or direct access to networking and computing resources. M-22-18 gave it earlier attestation collection deadlines than other software, and M-23-16 kept that split. M-26-05 later rescinded both memos.
The definition in the order
Section 4(a) of EO 14028 describes "critical software" as software "that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources)." Section 4(g) told NIST to publish a definition that reflects:
- the level of privilege or access required to function,
- integration and dependencies with other software,
- direct access to networking and computing resources,
- performance of a function critical to trust, and
- potential for harm if compromised.
Section 4(h) then asked CISA to publish a list of software categories meeting that definition, for agencies to use.
How the memos used it
M-22-18 split its timeline in two. Agencies were to collect attestation letters for critical software within 270 days of the memo and for all in-scope software within 365 days. It also said that an agency could decide a third party assessment was needed "due to the criticality of the service or product," using the M-21-30 definition.
M-23-16 replaced the clock. It said agencies must collect attestations for critical software no later than three months after OMB approved the common form under the Paperwork Reduction Act, and for all other in-scope software six months after.
| Memo | Critical software deadline | All other in-scope software |
|---|---|---|
| M-22-18 | 270 days after the memo | 365 days after the memo |
| M-23-16 | 3 months after PRA approval of the form | 6 months after PRA approval of the form |
Why the split mattered to suppliers
If your product ran with high privilege inside an agency network, such as identity, endpoint or network management software, you were likely to be asked first. A producer in that position benefited from having evidence ready before the agency sent a request. For other products, the later date gave more time.
Criticality could also change the type of assurance. M-22-18 called self-attestation "the minimum level required" and let agencies make a risk-based call that more was needed.
Where things stand
OMB M-26-05, dated January 23, 2026, rescinded M-22-18 and M-23-16. The deadlines above no longer drive agency activity. The memo does say each agency should validate provider security "based on a comprehensive risk assessment," and that agencies must keep a complete inventory of software and hardware. The idea of treating high privilege software with extra care is therefore still reasonable risk practice, even though the dated schedule is gone.
A practical takeaway
Ask yourself whether your product is the kind of software an agency would treat as high risk. If yes, prepare for questions beyond a form: artifacts, an SBOM, and perhaps independent assessment. If you are unsure whether a given contract still cites the old memos, search for "M-22-18" and ask your contracts team.
Quick check
Who decides whether my product is critical software?
The order directed NIST to define the term and CISA to list categories. In practice a given agency decides how it applies to its own purchases, so ask the requester.
Do the 270 day and 365 day deadlines still apply?
They were in M-22-18, which M-26-05 rescinded. Check any contract that still cites them.
Sources
Last reviewed: 19 October 2026.
