CISA launched the Secure by Design pledge in May 2024 with about 60 inaugural signatories and a set of seven goals that signatory vendors committed to advance over the following year. By May 2025, the pledge had grown past 150 signatories and CISA opened a "Progress Reports" page where vendors began publishing their year-one self-assessments. The first wave — BeyondTrust, Google, Cisco, DataMotion, Trend Micro, and others — gives the public the first concrete look at how a voluntary, non-binding industry commitment actually translates into engineering outcomes. The picture is mixed: real progress on MFA and default-password elimination, slower progress on vulnerability-class reduction, and almost no measurable movement on customer-facing logging defaults.
What were the seven pledge goals, and how is progress measured?
The seven goals are: multi-factor authentication, default passwords, reducing entire classes of vulnerability, security patches, vulnerability disclosure policy, CVE accuracy, and evidence of intrusions (customer-facing logging). Each goal has CISA-suggested measures rather than hard metrics; signatories chose how to operationalize them. The published progress reports vary widely in rigor. Some vendors report percentages — "MFA enabled for 94% of administrator accounts on our SaaS plane" — while others restate policies without numbers. CISA has not standardized the report template, which makes cross-vendor comparison difficult and is the most-cited complaint from industry analysts.
Where did signatories make the most measurable progress?
Multi-factor authentication and default password elimination led. BeyondTrust's report claimed elimination of universal default passwords across its product line and MFA enforcement for all customer-facing administrator roles. Google's progress report described enabling phishing-resistant MFA by default for new Workspace customers and reported significant reductions in successful credential-stuffing against signatory products. Cisco described expanded MFA enforcement on cloud-management consoles and the deprecation of weak default credentials on multiple network appliance lines. The pattern across reports is that "policy can be changed with an engineering sprint" — toggling MFA defaults, removing shipped passwords — was the lowest-friction path to demonstrable progress.
Where did vendors fall short or stall?
Reducing entire classes of vulnerabilities, the goal most aligned with memory-safe languages, secure-by-default APIs, and architectural change, showed the least concrete movement. Several reports cite "ongoing Rust migration" or "expanded fuzz testing" without quantifying the resulting CVE reduction. Customer-facing logging — providing audit logs at no additional cost — also lagged: a handful of vendors made logging tier-inclusive, while many continued to gate audit trails behind premium SKUs. CISA's own commentary on the progress page acknowledges these as "areas requiring sustained focus."
| Goal | Strong progress | Weak progress | | --- | --- | --- | | MFA | Default-on for admin roles | Customer end-user MFA still optional | | Default passwords | Eliminated in most reports | Legacy appliance lines lag | | Vulnerability classes | Memory-safety roadmaps stated | Few quantified CVE reductions | | Security patches | Reduced patch latency claimed | No standardized SLA reporting | | VDP | Most signatories now have one | Quality and responsiveness varies | | CVE accuracy | CWE coverage improving | Many CVEs still lack CWE/CVSS detail | | Customer logging | Some tier-inclusion announced | Audit logs frequently still paywalled |
What is CISA doing to keep momentum?
CISA stated in March 2025 that progress reports are intended to be annual, with vendors expected to publish year-two updates on the same timeline. The agency has signaled (without committing) that future reports may include more standardized measures. Pledge participation itself is not enforceable — CISA cannot penalize a non-progressing signatory — but the public-reporting format creates reputational pressure that several vendors have referenced internally as a driver. Procurement language is starting to require signatory status in federal and state RFPs, which adds material weight to what would otherwise be a voluntary signaling exercise.
What is the pledge's relationship to procurement and federal acquisition?
Pledge participation has begun to flow into procurement language even though CISA itself has no contracting authority. Several federal acquisition vehicles updated in late 2024 and through 2025 reference Secure by Design as an evaluation factor for software-licence purchases, and state-level CIOs (notably in California, Texas, New York, and Virginia) have published procurement guidance asking vendors to either join the pledge or provide equivalent evidence. The Federal Acquisition Regulation (FAR) updates implementing the post-EO-14028 Self-Attestation Common Form already required software producers to attest to specific SSDF practices; the Secure by Design pledge fits alongside that requirement as a public, dated artifact that procurement officers can verify in seconds rather than chasing PDF attestations through a vendor's compliance portal. Enterprise procurement teams treating the pledge as one input among many — alongside SOC 2 reports, ISO 27001 certificates, and SSDF self-attestations — get a fuller TPRM picture than relying on any single artifact. Vendors that signed but did not publish year-one reports occupy an awkward middle ground in this analysis: visible commitment, no visible delivery.
How should enterprise buyers read these reports?
Treat them as evidence, not certifications. Specifically: check whether the vendor reported numeric measures or only policy statements (numbers indicate seriousness), verify the customer-facing logging claim against your actual contract terms (paywall language often contradicts pledge claims), look for CWE breakdown of vulnerability-class progress (Rust migrations should produce visible memory-safety CVE declines), and confirm the vendor's VDP is live and responsive (submit a test report). For TPRM teams, the progress reports become a structured artifact that complements SOC 2 and ISO 27001 evidence — they tell you what a vendor's product engineering organization actually prioritized in the last twelve months.
How does the pledge interact with international Secure by Design efforts?
CISA's pledge is the highest-profile Secure by Design initiative but not the only one. The UK NCSC, Australia's ACSC, Canada's CCCS, and the EU's ENISA have all issued aligned guidance, and joint Secure by Design publications co-authored across these agencies have become regular outputs. The international convergence matters because vendors selling to multinational customers face overlapping but not identical requirements; the alignment between US, UK, and EU expectations reduces the compliance friction for global products. The pledge's seven goals map closely to the international guidance, with minor wording variations, and signatory vendors largely report progress in ways that satisfy multiple jurisdictions simultaneously. Vendors that have not engaged with any of the Secure by Design initiatives are increasingly visible as outliers, both to enterprise procurement and to government acquisition. By 2026, expect the convergent international guidance to be referenced in EU AI Act conformity assessments, in UK government procurement, and in Australian critical-infrastructure regulation, raising the practical cost of non-engagement.
How Safeguard Helps
Safeguard's TPRM module ingests CISA Secure by Design pledge signatory status and links to the vendor's progress report (where published), tracking year-over-year delta on the seven goals. Griffin AI parses each report and extracts numeric claims — MFA percentages, patch latency, vulnerability-class progress — into structured fields that can be filtered and trended across your vendor portfolio. Policy gates can require pledge-signatory status for specific procurement tiers, and flag vendors whose progress reports omit numeric measures or skip a year. For enterprises building their own pledge response, Safeguard generates a progress-report skeleton populated from the platform's own data: MFA enforcement statistics from your IdP integration, default-password posture from your asset inventory, vulnerability-class trend lines from your finding history, and customer-logging coverage from your product configuration audit. That turns the year-two report from a quarter-long writing exercise into a one-week review.