The CISA attestation form lets you choose company-wide, individual product, or multiple products or specific versions. A company-wide statement is simplest when every product follows the same practices. Choose product-level when practices differ, because each listed product then needs its name, version and release date.
The three options on the form
Section I of the form has a "Type of Attestation" line with three boxes:
- Company-wide. The statement covers the producer's software in general.
- Individual product. You name one product, with version number and release or publish date where applicable.
- Multiple products or specific product versions. You provide a complete list.
A separate row lets you mark whether this is a new attestation, one following an extension or waiver, or a revised attestation.
What the memo preferred
M-22-18 described what an acceptable attestation must include: the producer's name and a description of which products the statement refers to. It said that description should preferably be "focused at the company or product line level and inclusive of all unclassified products sold to Federal agencies." It also told agencies to encourage producers to be "product inclusive so that the same attestation may be readily provided to all purchasing agencies."
M-22-18 was rescinded by M-26-05 in January 2026, so treat this as history that explains the form's design, not as a current instruction.
Decision table
| Your situation | Likely fit | Reason |
|---|---|---|
| One build pipeline and one set of controls for every product | Company-wide | One statement stays true across the catalog |
| Two product lines with different build systems | Multiple products, grouped by line | Lets you list what each line does |
| An acquired product still on legacy tooling | Individual product | Avoids overstating practices for the older codebase |
| A hosted service on continuous delivery | Company-wide or product, with care | The form notes SaaS delivers continuous changes, so versions move quickly |
A test before you tick company-wide
Ask one question for each product: would every Section III practice be true today, for this team? The practices include separated build environments, multi-factor authentication, automated vulnerability checks before release and a vulnerability disclosure program. If any answer is no for one product, a company-wide box would claim more than you can support.
A footnote on the form says attestations are binding for future versions of the named product unless the producer notifies the agencies that its development practices no longer conform. That makes a broad scope a longer commitment, so match the scope to what you can keep true.
Keep the scope aligned with the evidence
Whatever you choose, keep an evidence folder organized the same way. If the attestation is per product, the folder is per product. If you later add a product line, decide whether it falls under the existing statement or needs a revised attestation, and ask your contracts team before assuming.
Quick check
Can one attestation cover several agencies?
M-22-18 encouraged producers to make one attestation usable by all purchasing agencies. The common form is built so the same document can be given to more than one.
Do we list open source components in the product table?
No. The form states that it covers code developed by the producer, and third party components are listed as out of scope, although you still attest to managing the risk they bring.
Sources
Last reviewed: 19 October 2026.
