The Cybersecurity and Infrastructure Security Agency's Secure by Design Pledge, launched 8 May 2024 at RSA Conference, was never meant to stay voluntary forever. In its January 2026 quarterly update, CISA confirmed the pledge has crossed 300 signatories and published a progress report describing how the agency now expects signatories to produce evidence, not aspirations. That shift — from signing a commitment to demonstrating it — is what separates 2024 marketing from 2026 compliance work.
This post translates the pledge's seven goals into engineering and GRC artefacts your team can produce before a customer, auditor, or journalist asks for them.
What exactly did signatories commit to in the Secure by Design Pledge?
The pledge, published by CISA on 8 May 2024 and still anchored at cisa.gov/securebydesign/pledge, sets out seven concrete goals with a 12-month measurable-progress window. Signatories agreed to (1) materially increase multi-factor authentication adoption across their products, (2) reduce default passwords to zero, (3) reduce entire classes of vulnerabilities such as SQL injection and memory safety issues, (4) increase installation rates for security patches, (5) publish a vulnerability disclosure policy that authorizes good-faith research, (6) ensure CVE records are complete and accurate, and (7) demonstrate meaningful improvement in customers' ability to detect intrusions into their products.
The word "measurable" is the one regulators, insurance carriers, and procurement offices have fixated on. CISA's January 2026 progress report explicitly notes that narrative descriptions of effort are no longer sufficient — the agency expects before/after metrics, published roadmaps, and customer-visible changes.
Who joined in the 2026 cohort and why does it matter?
Early signatories in 2024 skewed toward large, well-resourced vendors — AWS, Microsoft, Google, Cisco, IBM, HPE, Fortinet, Palo Alto Networks, Okta, Cloudflare and others on the original public list. The 2025–2026 cohorts broadened the pledge into mid-market B2B SaaS, developer tooling, and critical-infrastructure OEMs. CISA's January 2026 update highlighted signatories from industrial control system vendors, medical device firms, and a noticeable increase in open-source foundations signing on behalf of their flagship projects.
The practical effect is that enterprise buyers now treat pledge status as a procurement filter. A growing number of federal RFPs reference the pledge directly in section L evaluation criteria, and several state government frameworks — notably California's Department of Technology guidance updated in February 2026 — point to pledge signatory status as a positive indicator during vendor due diligence.
If you are not a signatory, you need a defensible story for why. If you are, you need evidence.
How is CISA measuring progress against the seven goals?
CISA's public scorecard methodology, described in the 2026 progress report and in the agency's Secure by Design Alert series, evaluates signatories on four evidence buckets. First, published artefacts — vulnerability disclosure policies, SBOM availability, CVE program participation records, and security.txt files. Second, product telemetry — aggregate MFA adoption rates, default-credential elimination schedules, and patch installation rates reported in semi-annual updates. Third, incident response posture — how quickly CVEs are published after fix availability and whether root cause analyses are shared under the agency's "Secure by Design Alert" template. Fourth, customer logs and detection capability — whether products emit the audit events needed for customers to detect lateral movement, a theme CISA has hammered since the 2023 Storm-0558 Microsoft Exchange Online compromise.
Nothing in this framework is exotic. What is new is that CISA now requests the underlying data when a signatory claims progress. Vague blog posts attract polite but pointed follow-up emails from CISA's Technical Operations Branch.
What are regulators doing with pledge commitments?
The Federal Trade Commission has begun citing Secure by Design principles in consent decrees — most visibly in its 2025 Drizly follow-on order and in 2026 settlements involving identity providers. A pledge commitment is, in the FTC's Section 5 framing, a material representation to consumers. Walking it back without disclosure is a deceptive practice risk.
Federal civilian agencies, bound by OMB Memorandum M-22-18 and its September 2023 amendment M-23-16, require self-attestations from software producers per the CISA Secure Software Development Attestation Form (OMB Control Number 1670-0052, approved March 2024). Pledge commitments and attestation claims are now read side-by-side. Diverging stories — "secure by default" on your website, "out-of-scope" on your attestation — are exactly the pattern that draws Inspector General scrutiny.
State attorneys general have also discovered the pledge. New York's Office of the Attorney General cited the pledge in its August 2025 assurance of discontinuance with a SaaS identity vendor, and the Washington State AG's office released a 12 March 2026 guidance document referencing pledge language when evaluating breach notification adequacy.
What evidence should a signatory be able to produce on demand?
A defensible Secure by Design evidence package in 2026 looks roughly like this. For MFA: a dated report of MFA enforcement rates per product tier, with a roadmap line item closing the remaining gap. For default passwords: a product inventory showing the default-credential posture of every shipping SKU, with firmware cutover dates. For vulnerability classes: a program document describing the memory-safety or injection-class elimination strategy, with metrics on reduction over time. For patching: telemetry on patch installation rates and an explanation of any drop-offs. For VDP: the public policy URL, a security.txt file, and statistics on researcher reports received and fix times. For CVEs: evidence of CNA participation or a clear process with your assigning CNA. For detection: a documented list of audit events your product emits, mapped to MITRE ATT&CK techniques your customers are expected to detect.
These artefacts should live in a single evidence room — not scattered across engineering wikis, marketing pages, and Salesforce attachments. When CISA, an enterprise procurement officer, or a regulator asks, the answer needs to take minutes, not weeks.
Where does the pledge intersect with SBOM and attestation mandates?
The pledge itself does not require you to ship SBOMs. But five of its seven goals become dramatically easier to demonstrate when you already produce machine-readable SBOMs per the NTIA minimum elements and sign your build artefacts. Vulnerability-class reduction claims are verifiable against SBOM component inventories. Patch installation metrics become credible when tied to artefact digests recorded in an in-toto attestation. CVE record completeness is a function of how well you track affected versions — which, again, is an SBOM problem.
The intersection with OMB M-22-18 attestations is even tighter. The CISA attestation form requires producers to attest that they follow NIST SP 800-218 Secure Software Development Framework practices. Pledge goals 3, 6, and 7 are SSDF practices in plain English. If your attestation posture is weak, your pledge posture is a press release.
How Safeguard.sh Helps
Safeguard.sh turns the Secure by Design Pledge from a marketing statement into a live control surface. Lino, our compliance mapping engine, maps each of the seven pledge goals to concrete evidence requirements across NIST SSDF, NIST SP 800-161 Rev. 2, ISO/IEC 27001:2022, and the CISA Secure Software Development Attestation Form (OMB 1670-0052), so you can see which of your existing controls already satisfy the pledge and which need work. Safeguard.sh generates and continuously validates CycloneDX and SPDX SBOMs per the NTIA minimum elements, giving you the component-level telemetry needed to substantiate vulnerability-class reduction and CVE completeness claims. Our TPRM module ingests third-party vendor attestations and pledge-signatory status into your supplier inventory, making it straightforward to filter vendors by pledge posture during procurement. Finally, Safeguard.sh's attestation and signing service produces in-toto and SLSA-aligned provenance for every release, signed via Sigstore or your customer-managed KMS, so that when CISA, the FTC, or a state AG asks for evidence, you deliver verifiable artefacts — not slide decks.
The organizations that treated the 2024 pledge as a commitment rather than a branding exercise are the ones sailing through 2026 procurement reviews. The rest are learning that regulators read their own press releases.