CISA launched the Secure by Design pledge at RSA Conference in May 2024 with 68 founding signatories and a clean, public commitment structure: seven goals, public progress reports, and a one-year measurement window from each signatory's enrollment date. Two years on, the pledge has cleared 250 signatories. Crucially, signing organizations have begun publishing their first and second annual progress reports on cisa.gov, which gives the rest of the industry something concrete to read against. This post walks through the goal structure, what the reports actually contain, and how to use them when evaluating an upstream supplier in 2026.
What does the Secure by Design pledge actually require?
The pledge is a public, voluntary commitment to make "measurable progress" against seven goals within one year. Goal one covers multi-factor authentication: increase the proportion of customers using MFA, with phishing-resistant MFA on the manufacturer's own production systems. Goal two addresses default passwords: eliminate them in newly shipped products, or where unavoidable, require user customization on first use. Goal three targets one or more whole vulnerability classes (SQL injection, command injection, cross-site scripting, memory unsafety) for systematic reduction through architectural choices. Goal four covers security patches: increase customer installation rates and reduce time between availability and installation. Goal five is vulnerability disclosure: publish a policy that authorizes testing, allows researchers to report findings, and commits to non-retaliation. Goal six requires publishing CVE records that are complete and accurate, including the CWE root cause. Goal seven asks manufacturers to publish evidence of intrusions on customer systems where the manufacturer's product was the attack vector. The pledge is not certification; it is a public commitment with public artifacts.
Who has signed, and is the list still growing?
The initial 68 signatories included Microsoft, Google, AWS, IBM, Cisco, Fortinet, GitHub, GitLab, Okta, HashiCorp, Tenable, and SentinelOne. CISA reported the list crossed 200 in 2025 and continued expanding through early 2026. Signatories now span foundation-model providers, identity vendors, network appliance OEMs, observability platforms, and the larger application security tooling ecosystem. The signatory list is not vendor neutral in distribution: enterprise infrastructure and developer-tools vendors are over-represented, while consumer software, IoT, and OT vendors remain under-represented despite operating products that frequently appear in CISA's Known Exploited Vulnerabilities catalog.
What do the public progress reports look like?
Progress reports are short — typically a single PDF or web page per company — and structured by goal. Microsoft's first-year report described MFA enforcement for production engineers, the elimination of default credentials in newly shipped Azure services, and progress on a memory-safety initiative across Microsoft 365 components. Google's report covered Workspace MFA adoption, sandboxing improvements in Chrome, and CVE record completeness commitments. Cisco's report focused on default-credential elimination in IOS XE, expanded vulnerability disclosure, and CVE quality (including CWE assignment on every advisory). Fortinet's first-year retrospective explained measurable adoption metrics for FortiCloud MFA, default-password changes across product lines, and PSIRT publication norms. Some reports include numerical baselines and current values; others remain qualitative. The variability is itself information for buyers: a supplier that publishes percentages and trend arrows is operating a more mature program than one that publishes only narrative.
Where are the published commitments thin?
Goal three (whole-class vulnerability elimination) and goal seven (evidence of intrusions) are the most uneven. Several signatories described intent rather than measurable reduction for whole-class work, especially around memory safety in legacy C and C++ codebases. Goal seven is even thinner: very few reports include data on intrusions where the manufacturer's product was the initial attack vector, despite explicit pledge language calling for that disclosure. CISA has not publicly named gaps in specific reports, but the trade press has, and that pressure is shaping what the second-year reports look like. Goal four (patch installation rates) also remains under-reported because most manufacturers do not have telemetry into customer environments and have to fall back on update-channel statistics.
How should buyers use the pledge in vendor selection?
The pledge is best used as a filter, not a verdict. Three practical applications. First, treat the signatory list as a baseline expectation for any new strategic supplier in scope of EO 14144 self-attestation, the CISA Secure Software Acquisition guide, or sector-specific procurement language. Second, require the supplier to share its progress report alongside any SOC 2 or ISO 27001 report it provides in due diligence; non-signatories should be asked to explain why. Third, compare two or more shortlisted vendors on the same goal — for example, default-password elimination — using their own published numbers, and use the comparison as part of the technical evaluation. A pledge signature without a substantive progress report is a weaker signal than no signature at all.
# Secure by Design vendor questionnaire excerpt
1. Is the vendor a Secure by Design pledge signatory? (cisa.gov/securebydesign/pledge)
2. Provide the most recent progress report URL.
3. For Goal 1 (MFA): % of paid customers with MFA enabled, latest reporting period.
4. For Goal 2 (default passwords): are they eliminated in newly shipped products?
5. For Goal 3 (vulnerability classes): which class is targeted? What metric is used?
6. For Goal 4 (patches): median time from patch availability to installation?
7. For Goal 5 (disclosure): URL of the vulnerability disclosure policy.
8. For Goal 6 (CVE records): does every advisory include a CWE root cause?
9. For Goal 7 (evidence of intrusions): are there public post-incident reports?
What about EO 14306 and the future of self-attestation?
EO 14306, signed June 6, 2025, streamlined EO 14144 by removing the most prescriptive elements of the federal software self-attestation regime, including the requirement that suppliers submit machine-readable artifacts and that CISA audit a sample. The Secure by Design pledge, which is voluntary and operates outside the self-attestation regime, was unaffected. In practice, the pledge has become the most visible public reference point for what "secure development" should look like, filling part of the vacuum left by the EO 14144 rollback. Procurement and security teams who built supplier-evaluation playbooks around the pledge in 2024 and 2025 have not had to rewrite them; they have only had to lean harder on it.
How Safeguard Helps
Safeguard tracks Secure by Design pledge participation as a structured signal in its supplier risk graph, flagging signatories whose progress reports are missing, stale, or qualitatively thin against goal-specific baselines. Griffin AI compares supplier-published progress data against observable evidence in CVEs, KEV entries, and public incident reports tied to those vendors, so security teams can spot the gap between pledge language and operational reality. TPRM workflows automatically attach the supplier's most recent progress report to its vendor record and resurface it during contract renewal. Policy gates can require that any new strategic vendor in scope of federal or regulated procurement provide a pledge artifact alongside SOC 2 or FedRAMP evidence, making the pledge a usable, enforceable input rather than a one-time marketing claim.