When CISA launched the Secure by Design Pledge in 2024, it was a voluntary commitment asking software manufacturers to align with seven measurable goals. The list was deliberately non-exhaustive and signatories were trusted to self-report. Skeptics, myself included, worried that this would become another logo on marketing pages with nothing behind it.
Two years in, the picture is more interesting. The pledge did not transform the industry overnight, but it changed the conversation inside enough engineering organizations to be worth a serious retrospective. Here is what has actually moved, and what is still stuck.
What did the pledge change inside product teams?
The MFA default goal moved the needle most visibly. Signatories committed to enabling MFA as a default for privileged users across their products within a year of signing. By early 2026, roughly 85 percent of pledge signatories have delivered on this for admin accounts, and the laggards are publicly visible because CISA has been firm about not granting extensions. For SaaS products especially, this has closed a long-running argument about whether MFA should be opt-in versus opt-out.
Default password elimination has been another solid win. Signatories removed universal default credentials from shipped devices and products, replacing them with unique per-device provisioning or forced setup flows. This mattered most for OT and IoT vendors, who historically resisted the operational overhead. The pledge made the resistance harder to justify internally.
Reducing entire classes of vulnerabilities, the memory safety goal, had the messiest trajectory. Some vendors published serious roadmaps to Rust or other memory-safe languages for new code. Others produced PDFs that were aspirational at best. CISA has been public about this unevenness, which is itself valuable, but the goal remains more aspirational than operational for most signatories.
Where did the pledge fail to create behavior change?
The CVE completeness goal was supposed to get vendors to publish CVE records for every critical vulnerability in their products. In practice, vendors still underreport. Many bugs that meet the CVE threshold get quietly fixed with no ID assigned, partly because internal teams lack the workflow to file CNA submissions, and partly because product managers still view CVEs as reputational liabilities.
The vulnerability disclosure program goal suffered the same fate as its EO 14028 cousin. Signatories now mostly have a VDP page, but the quality of coordinated disclosure still varies enormously. Having a page does not guarantee that a submitted report will reach an engineer who can act on it within a reasonable window.
The evidence of intrusions goal, committing to give customers the telemetry they need to detect compromise, has been the least tangible. Defining "sufficient logging" is hard, and customer expectations range from "I want syslog" to "I want structured events with entity IDs for every privileged action." The pledge did not resolve that ambiguity and signatories have interpreted it generously.
How are procurement teams using pledge status in 2026?
The pledge has quietly become a procurement signal. I have seen RFPs that explicitly ask whether a vendor is a pledge signatory and, if so, for evidence of progress against each goal. CISA publishing the list of signatories created a soft form of accountability that procurement offices now use.
What this means practically is that signing and then under-delivering is worse than not signing at all. Several vendors have learned this the hard way after customers pulled the public self-reporting and asked pointed questions during QBRs. The pledge is voluntary, but the reputational cost of visible under-performance is real.
Non-signatories are in a more complicated spot. Some customers treat non-signing as a red flag. Others, especially in regulated industries, have their own frameworks and see the pledge as duplicative. The default stance from mid-market and enterprise customers is increasingly to ask signatories why they have not hit their timeline, and to ask non-signatories why they did not sign.
What do the 2026 pledge updates actually demand?
CISA updated the pledge guidance in late 2025, tightening expectations around evidence and cadence. Signatories are now expected to publish semi-annual progress reports mapped to each of the seven goals, with measurable metrics rather than narrative updates. That is a significant shift.
The MFA goal was expanded to require phishing-resistant MFA for privileged users, not merely MFA. This pushes signatories toward FIDO2 and WebAuthn and away from SMS and TOTP for admin roles. For most SaaS products, this is achievable. For legacy enterprise software, it is a serious lift that some signatories will not complete on time.
The reducing vulnerability classes goal now includes a more explicit expectation around SBOMs and dependency hygiene. Signatories should be able to demonstrate that they know what components ship in their products and that they have a process for responding to vulnerabilities in those components. This is where the pledge intersects with EO 14028 and where procurement questionnaires are getting denser.
What should engineering leaders prioritize if they signed?
Treat the pledge like a roadmap commitment, not a marketing event. Pick the goals that have the most operational leverage for your product, resource them accordingly, and make progress visible inside the organization. The companies that have embedded pledge goals into their OKRs have outperformed the ones that left it to security to drive.
Build the evidence pipeline before you need it. The 2026 progress reporting expectations mean that if you cannot pull metrics on MFA coverage, CVE issuance, and vulnerability class reduction on demand, you will spend the weeks before each report scrambling. Instrument this now.
Do not underestimate the SBOM and dependency piece. The pledge is converging with EO 14028 and private sector compliance frameworks on a common expectation: you should know what is in your software, you should monitor it for vulnerabilities, and you should respond with published VEX statements when appropriate. This is where most under-resourced signatories are going to struggle in the next reporting cycle.
How does the pledge intersect with international frameworks?
Companies selling globally have noticed that pledge progress maps cleanly to several international frameworks. The EU Cyber Resilience Act expectations around security-by-default and default secure configurations align with two pledge goals. The UK's Product Security and Telecommunications Infrastructure Act overlaps on default password elimination. Pledge progress reports can double as supporting evidence in both regulatory contexts with minor tailoring.
This is not a coincidence. The same engineering investments that satisfy CISA's pledge also address most modern product security expectations. Treating the pledge goals as a unified roadmap rather than a US-specific compliance exercise pays off when international obligations arrive.
What this means for engineering leaders is that pledge-aligned investments are not throwaway spend. The MFA rollout, the default-password work, the vulnerability class reduction programs all have payback across multiple jurisdictions. Framing pledge work that way makes it easier to get internal funding and executive attention.
How Safeguard.sh Helps
How Safeguard.sh Helps
Safeguard.sh operationalizes the Secure by Design Pledge goals that depend on dependency hygiene and vulnerability response. Our reachability engine reduces 60 to 80 percent of SBOM-derived CVE noise so your engineers are fixing what actually matters, making the "reduce entire classes of vulnerabilities" goal tractable rather than theoretical. Griffin AI generates pledge progress evidence mapped to each of the seven goals, with SBOM, TPRM, and 100-level transitive dependency analysis feeding the reports your signatory status now demands. Container self-healing keeps your base images patched automatically, directly supporting the default secure configurations and memory safety commitments you made.