The Cybersecurity and Infrastructure Security Agency launched its Secure-by-Design pledge at RSA Conference in April 2024, building on the joint CISA/NSA/FBI guidance from October 2023 and the international "Shifting the Balance of Cybersecurity Risk" paper from earlier that year. The pledge is explicitly voluntary, frames seven product-security goals that signatory vendors commit to making "measurable progress" on within one year, and is designed to shift the historical norm in which software vendors disclaim responsibility for the security of what they ship. As of early 2026, more than 250 organizations have signed, including most of the large enterprise platform vendors, several of the cloud hyperscalers, and a long tail of mid-market security and infrastructure companies.
The pledge does not have legal force, and a signatory who fails to make progress on any of the seven goals faces no civil penalty and no regulatory enforcement action. What it does have is reputational weight, procurement leverage, and (increasingly) implicit incorporation into federal acquisition language. Two years in, the more interesting story is not the pledge text itself but how procurement teams at large enterprises and federal civilian agencies are using the pledge as a baseline expectation, asking signatory vendors to show their work, and treating non-signature as a yellow flag in vendor risk assessments.
What did signatories actually commit to?
The pledge sets seven goals: a measurable increase in multi-factor authentication adoption across the vendor's products, a measurable reduction in the use of default passwords, a measurable reduction in entire classes of vulnerability (the canonical example is memory-safety vulnerabilities through adoption of memory-safe languages, but the goal is broader), a measurable increase in installation of security patches by customers, a published vulnerability disclosure policy that authorizes good-faith security research, transparency in vulnerability reporting through complete and accurate CVE issuance, and providing customers with the evidence (logs, telemetry) needed to detect intrusions affecting the vendor's product.
Each goal is paired with examples of what "measurable progress" looks like, but CISA explicitly avoided prescribing metrics. The agency's framing is that signatories know their products best and should set their own baseline and trajectory, and then publish progress against that baseline. That choice produced some early skepticism — without a common metric, comparing vendors is hard — but it also produced concrete commitments that the agency could not have credibly negotiated in a more prescriptive form. A vendor that commits to "reduce default-credential exposure by 80% in our flagship product over twelve months" has put down a number a customer can ask about.
The pledge also includes a soft commitment to publish a Secure-by-Design "roadmap" within one year of signing, and to provide ongoing updates. By mid-2025 most signatories had published something, ranging from detailed multi-year roadmaps (Microsoft, Google, AWS, Cisco) to brief blog posts. The variance in seriousness across the signatory pool is itself useful information for procurement teams.
Where has progress been concrete in 2026?
The clearest progress has been on default-credential elimination, which is a goal where the engineering work is tractable and the customer-facing impact is immediate. Several enterprise networking vendors have shipped products in the last year that require credential rotation at first boot, refuse to operate with manufacturer defaults, and surface credential-hygiene telemetry to administrators. CISA's Known Exploited Vulnerabilities catalog has tracked a meaningful decline in newly cataloged default-credential CVEs from signatory vendors, although the data is noisy and one year of post-signature data is not enough to claim victory.
Memory-safe language adoption is the goal where the largest signatories have invested the most public capital and where progress is the most uneven. Microsoft has published quarterly updates on Rust adoption in Windows components. Google has continued its Android memory-safety work. Several smaller signatories have committed to writing new components in memory-safe languages but have made no commitment to rewriting existing C/C++ code. That asymmetry is realistic — rewriting decades of legacy code is not a one-year project — but it means procurement teams asking about memory-safety progress should ask about the boundary: which new components, which existing components, and what is the trajectory.
Multi-factor authentication adoption inside vendor-shipped products is the goal where the data is hardest to read, because adoption is mediated by the customer's configuration choices. Several signatories have moved to MFA-by-default for administrative consoles, which is the meaningful change, but the broader "increase MFA adoption" goal continues to be reported in adoption percentages that are not directly comparable across vendors. The published vulnerability disclosure policy goal is the one with the highest signature-to-completion rate; almost every signatory now has a vendor-published VDP that meets ISO 29147 baseline expectations.
How is procurement using the pledge?
The pledge is showing up in procurement language in three ways. Federal civilian agencies, working under the OMB guidance that flows from Executive Order 14028, are adding pledge-aligned questions to their vendor questionnaires — not requiring signature, but asking the same substantive questions the pledge frames. Large private-sector enterprises with mature third-party risk programs have incorporated pledge alignment as a scored factor in vendor selection, with one of the major retail conglomerates publicly stating in early 2025 that pledge signature is a tiebreaker in software procurement. Insurers writing cyber coverage have begun asking about pledge alignment as part of underwriting questionnaires, although it is not yet a rate factor.
The interesting downstream effect is on non-signatories. A vendor that has chosen not to sign now has to explain that choice when a customer's procurement team asks, and "we did not sign because the pledge is too prescriptive" lands differently than "we did not sign because we are working on the same goals through a different framework." Several pre-IPO security vendors have signed specifically because the absence of signature was generating questions in customer calls. The pledge has acquired a market-signaling function the agency probably did not fully anticipate.
A subtler procurement effect is that the pledge has given buyers a vocabulary for asking about specific engineering practices without sounding like they are dictating engineering decisions. "Tell us about your progress on the third Secure-by-Design goal" is easier for a procurement officer to ask than "tell us about your memory-safety roadmap," and signatory vendors have committed to having an answer.
What should signatory vendors actually be doing in 2026?
The minimum bar in 2026 is a published progress report that addresses each of the seven goals with at least one measurable data point and at least one specific commitment for the coming twelve months. Vendors who signed at launch and have not yet published a progress update are starting to be asked about it explicitly. CISA has been consistent that the pledge is about progress, not perfection, but progress has to be visible and articulated.
The second-order bar is internal program structure: a named owner for each of the seven goals, quarterly metrics review at the executive level, and a public commitment process that survives leadership transitions. Several signatories who signed under one CISO have already gone through a CISO transition, and the pledge commitments need to be institutional rather than personal. Procurement teams asking about pledge commitments are increasingly asking about governance, not just about metrics.
The third-order bar — and the one most signatories have not yet reached — is integrating pledge progress with the customer-facing security artifacts that customers actually consume. SBOM publication, VEX (Vulnerability Exploitability eXchange) issuance, attestation of build provenance under SLSA, and CSAF security advisory feeds all map onto pledge goals, and customers who already consume these artifacts find it easier to evaluate pledge progress when the artifacts are present.
How Safeguard Helps
Safeguard gives signatory vendors the production-grade infrastructure to make pledge commitments measurable and consumable. The platform generates SBOMs as a continuous compliance artifact rather than a once-a-year deliverable, publishes VEX statements that map known vulnerabilities to actual exploitability in your shipping product, and collects attestation evidence (build provenance under SLSA, signed releases under Sigstore, software-supply-chain integrity claims) into a single source of truth that procurement teams can consume directly. Griffin AI maps your engineering work to specific pledge goals, surfaces gaps where commitments have outrun execution, and drafts progress-report language that survives procurement scrutiny. Policy gates in Safeguard block ingestion of suppliers who fail pledge-aligned standards, so your downstream supply chain meets the bar your customers expect of you. The result is that pledge commitments become operational artifacts your TPRM, audit, and procurement teams can use, not marketing language that lives on the website.