CISA's Secure-By-Design pledge has been one of the most prominent voluntary security commitments in the United States since its launch in 2024. The pledge invited software vendors to commit to seven goals: increased multi-factor authentication, default secure configurations, broader vulnerability disclosure, transparency, security patches, evidence of customer security improvements, and an explicit secure-by-design product development culture. Two years in, 2026 is a useful vantage point for looking at what signatories actually delivered, where the pledge succeeded as a forcing function, and where it is now being augmented by harder regulatory expectations.
What did signatories actually accomplish in the first two years?
The most visible progress was on multi-factor authentication. The pledge's MFA goal asked signatories to demonstrate measurable progress on enabling MFA across their products by default, particularly for administrative accounts. Many large signatories delivered on this, with default MFA enrollment for new tenants becoming common across enterprise SaaS in 2025 and 2026. The pattern shifted from "MFA available" to "MFA on by default," which is a meaningful change in real-world account security.
Default secure configurations also moved, though less consistently. Major cloud and infrastructure vendors tightened their out-of-the-box defaults, removed weak ciphers from default TLS configurations, disabled legacy authentication methods, and added secure-by-default options in areas like outbound network access and credential storage. Smaller vendors had a harder time because their customers expected feature parity with predecessors that had insecure defaults.
Vulnerability disclosure programs broadened, but the depth of those programs varied. The number of vendors with public security pages, security contacts, and coordinated disclosure policies grew substantially. The number of vendors who actually staffed those programs, met response timelines, and engaged constructively with researchers grew more slowly. The gap between policy and practice remains the most common failure mode.
Where did the pledge fall short?
The transparency and patches goals saw uneven delivery. Patch cadence improved at vendors that already had strong DevSecOps cultures and lagged at vendors that did not. Transparency about vulnerability rates, time to patch, and exploitation indicators is hard to standardize voluntarily, and few signatories published the kind of metrics that would let customers compare vendors directly.
The evidence of customer security improvements goal proved the hardest. Vendors were asked to demonstrate that their work was actually reducing customer security incidents. Causal claims of this kind are difficult, because customers' incidents depend on many vendors, on configuration choices, and on the threat environment. Most signatories satisfied the goal with leading-indicator metrics like default MFA adoption rates and reduction in known-vulnerable deployment counts, which is reasonable but not the same as outcome evidence.
The deepest cultural goal, the explicit secure-by-design product development culture, is the hardest to verify externally. Signatories described their internal practices, but external visibility into product development culture is limited. The pledge functioned as a public commitment that gave internal security advocates a tool for negotiating priorities, but the underlying cultural change is uneven.
How did the pledge interact with harder regulatory regimes?
The Secure-By-Design pledge is voluntary, but it co-existed through 2025 and 2026 with a tightening landscape of mandatory regulations. The EU Cyber Resilience Act, the SEC cybersecurity disclosure rules, sector-specific regulations from the FDA and FCC, and the executive orders on federal software procurement created harder expectations that the pledge anticipated but did not enforce.
The interaction has been complementary rather than competitive. Vendors who took the pledge seriously found themselves better positioned for the regulatory regimes, because the pledge's goals overlapped substantially with regulatory requirements. Vendors who treated the pledge as marketing found themselves scrambling when the regulations created real obligations.
A specific dynamic worth noting is that signatory status became a procurement consideration. Federal buyers, large enterprises, and increasingly state and local governments looked at pledge signatory lists when comparing vendors. The pledge effectively became a marker of seriousness in some markets, which created economic pressure to live up to the commitment beyond the original voluntary framing.
What is the second wave of CISA expectations?
CISA has been signaling through 2025 and 2026 that the original pledge is the starting point, not the destination. The conversation has expanded to cover memory safety, software identification, attestation of build integrity, and continuous vulnerability monitoring across deployed estate. These are harder asks than the original seven goals, and they map onto the deeper supply chain and provenance work that other US and international regulators are also pushing.
Memory safety, in particular, has moved from advisory language to concrete expectations for new products. CISA has been clear that critical infrastructure software written in memory-unsafe languages should have a remediation roadmap, even when full rewrites are impractical. Signatories are being asked to publish memory safety roadmaps with timelines, which is a significant escalation from the original pledge text.
Software identification through SBOMs has also tightened. The original pledge mentioned transparency without requiring specific artifacts. The successor expectations include shipping SBOMs with every release, signing them, and supporting consumer-side ingestion. This aligns with the broader US executive order pressure on federal software procurement and with international convergence around SBOMs as baseline expectations.
How are smaller vendors handling the expectations?
The pledge was easier for large vendors with security teams and budget. Smaller vendors, including many open-source maintainers, found the obligations harder to operationalize. The conversation through 2026 has been adapting to this reality, with foundation funding, commercial sponsorship of open-source security work, and tooling that lowers the cost of participation.
Some smaller vendors have effectively delegated parts of their secure-by-design posture to platforms. Cloud providers, package registry operators, and supply chain security platforms can provide signing, SBOM generation, vulnerability monitoring, and disclosure infrastructure as a service, which lets a small vendor offer pledge-grade controls without building them. This has created a tier of meta-compliance, where the platform is the vehicle for the small vendor's pledge-equivalent commitments.
The risk is that compliance becomes concentrated. If a few platforms underwrite the security posture of most small vendors, those platforms become single points of failure for the broader ecosystem. CISA's guidance through 2026 has been increasingly explicit that platform-mediated compliance is acceptable but does not relieve the vendor of accountability.
What changes for the rest of 2026?
Three changes are likely. First, the pledge will continue to evolve toward higher specificity. Voluntary commitments tend to start broad and tighten over time as the easy goals are achieved and the hard goals become the differentiator. Expect the next published expectations to be more measurable and more amenable to external verification.
Second, the pledge will increasingly intersect with procurement requirements. Federal procurement is already moving in this direction, and large enterprise buyers are following. Vendors who treated the pledge as optional are being told by customers that pledge-equivalent controls are now contractual.
Third, international convergence is accelerating. The UK, Canada, Australia, and EU governments have all been publishing secure-by-design or secure-by-default guidance that overlaps substantially with the CISA framing. Multinational vendors increasingly maintain a single secure-by-design program that covers all jurisdictions, because the variation between regimes is small enough to allow shared evidence.
How Safeguard Helps
Safeguard implements the operational substrate that secure-by-design commitments require. Lino compliance maps your delivery pipeline to CISA pledge goals and produces evidence for each: MFA posture, default configurations, vulnerability handling SLAs, patch cadence, and customer-impact metrics drawn from real telemetry. Continuous SBOM generation, signing, and distribution come through Eagle and the Safeguard ingestion API, with signed attestations that satisfy the second-wave expectations around build provenance. Griffin reachability analysis surfaces the exploitable subset of vulnerabilities so patch SLAs are scoped to what actually matters, and coordinated disclosure workflows are tracked end-to-end with audit trails. The pledge becomes a measurable program backed by data rather than a declaration that depends on goodwill.