The CISA Secure by Design pledge has quietly become a checkbox on enterprise security questionnaires. Buyers scan vendor trust pages for it. Sales teams ask their CISOs why the logo is missing. And because the pledge is voluntary and self-reported, the market now contains two kinds of signers: companies that signed a PDF, and companies that changed how they build software.
This guide is for the second kind, and for the buyers who need to tell the two apart. The pledge's seven goals decompose into ordinary, assignable engineering and security-program work. Most of it is design-phase work. None of it requires a press release.
What the pledge actually is
CISA published its Secure by Design guidance in April 2023, jointly with international cybersecurity partners, arguing that the burden of security should shift from customers to the vendors best positioned to remove risk at the source. In May 2024 it followed with the voluntary Secure by Design pledge: a public commitment by makers of enterprise software and services to pursue measurable progress against seven goals within a year of signing, and to be transparent about the results. Hundreds of companies have signed as of mid-2026.
Three properties matter for anyone operationalizing it. The goals are measurable: each asks for a demonstrable increase or reduction, not an aspiration. Progress is self-reported: there is no auditor, which makes published evidence the only meaningful signal. And the unit of commitment is the product portfolio, not the company: a signer is supposed to move the numbers across its products, which is what makes the work land in engineering rather than in marketing.
The seven goals, translated into work
Here is each goal as CISA frames it, the operational move behind it, and the evidence a buyer is entitled to ask for.
| Pledge goal | The operational move | Evidence a buyer can ask for |
|---|---|---|
| 1 · Multi-factor authentication | Make MFA the default, not an upsell: on by default for admins, nudged for everyone, enforced via standards like FIDO2 where the product allows | MFA adoption rate across the customer base, and the trend since signing |
| 2 · Default passwords | Eliminate shared and default credentials from setup flows; provision unique credentials or force rotation on first use | The date default passwords stopped shipping, and what legacy installs get |
| 3 · Reduce entire classes of vulnerability | Pick a class (injection, XSS, memory unsafety), then remove it structurally: safer frameworks, paved roads, parameterized-by-default libraries | Which class was chosen, the published reduction data, and the design changes behind it |
| 4 · Security patches | Make patching the easy path: auto-update channels, clear support windows, patches decoupled from paid upgrades | Patch uptake rates and the time customers typically run unpatched |
| 5 · Vulnerability disclosure policy | Publish a VDP with safe harbor for good-faith research and a working intake | The VDP URL, and whether reports get acknowledged and resolved |
| 6 · Transparent vulnerability reporting | Treat CVE records as documentation: timely filings with complete CWE and CPE data, including for issues found internally | Recent CVE records; check them for CWE classification and honest severity |
| 7 · Evidence of intrusions | Give customers the logs they need to investigate, in the base tier rather than behind a premium SKU | Which audit logs exist, their retention, and what they cost |
Read down the middle column and a pattern appears: not one of these moves is a security-team task in isolation. They are product decisions, framework decisions, release-engineering decisions, and pricing decisions. That is the pledge's real content: it asks the whole engineering organization to treat security outcomes as product requirements.
Where each goal actually lives
Assigning the goals to owners is where most signers stall, because the goals cut across four different layers of the organization.
Product defaults (goals 1 and 2)
MFA on by default and the end of default passwords are product-management and identity-engineering decisions, made in setup flows and provisioning code.
The design phase (goal 3)
Entire classes of vulnerability are removed in architecture and design reviews, framework choices, and paved roads, long before any scanner runs.
Release and operations (goals 4 and 7)
Patch uptake is a release-engineering problem; customer-facing audit logs are a platform decision, and a pricing decision.
Program and transparency (goals 5 and 6)
The VDP and complete CVE records belong to the security program: policy, intake, PSIRT discipline, and the willingness to document flaws honestly.
The layering explains a common failure mode. Companies that hand the pledge to the security team alone make quick progress on goals 5 and 6, which the security team controls, and never move goals 1 through 4, which it does not. The signature was corporate; the work is cross-functional. If your operating model has no forum where security, product, and engineering make binding design decisions together, that forum is the actual first deliverable. This is the same gap a security design review process exists to close.
Goal 3 is the one that separates signers
Six of the seven goals can be driven by determined program management. Goal 3, reducing entire classes of vulnerability, cannot, because a vulnerability class is not a bug backlog. It is a standing consequence of design decisions: which frameworks are permitted, where raw queries are allowed, which languages new services may use, what the paved road makes easy.
Removing a class therefore means changing how designs are made, not how findings are triaged. The teams that do this well run the same loop every time: pick one class, find where the design permits it, change the default so new designs cannot express the flaw, then burn down the legacy surface on a schedule. Parameterized queries as the only database path. Output encoding built into the template layer. Memory-safe languages for new network-facing code. Each of these is a design review policy first and an engineering migration second.
This is also where the pledge quietly rewards companies that already run security as a design-phase practice. If every significant design passes through review, with threats modeled against the architecture and controls mapped before build, then "which class are we eliminating next" becomes a routine roadmap question rather than a moonshot. That standing capability is exactly what a security architecture program is for.
How buyers should read a signature
The pledge's self-reported nature is not a weakness if you ask the follow-up questions. The signature tells you a company wanted the reputational benefit; the evidence tells you whether it did the work.
Signed the PDF
- The logo is on the trust page; the progress report is nowhere
- MFA exists but is off by default, or gated to premium tiers
- No vulnerability class named, no reduction data published
- Audit logs cost extra, retention is days, export is manual
- CVE records are sparse, late, or missing CWE data
Meant it
- Published progress, with numbers, within a year of signing
- MFA and unique credentials are the unconfigured default
- A named class of vulnerability with before-and-after evidence
- Security logs in the base tier with usable retention
- CVE records filed promptly, classified, and honest about severity
One caution in the other direction: absence of the logo is weak evidence. Plenty of disciplined engineering organizations never signed, and the questions in the table above work just as well on them. Ask the questions; skip the logo-scanning.
The Monday-morning moves
For a team that wants the substance with or without the signature, this is the work, ordered so the early items fund the later ones with credibility.
This month
- Publish a vulnerability disclosure policy with safe harbor and a monitored intake
- Set a CVE standard: file promptly, include CWE and affected-version data, apply it to internally found issues too
- Inventory where default or shared credentials still ship, and where MFA is off by default
This quarter
- Turn MFA on by default for administrative access in every product
- Kill default passwords in new installs; publish the plan for existing ones
- Move essential audit logs into the base tier and document their retention
This year
- Pick one vulnerability class and remove its preconditions from the paved road
- Route every significant design through a review that models threats against the architecture
- Publish the numbers: MFA adoption, patch uptake, the class-reduction data
The pledge as a forcing function
Treat the seven goals as a free, externally credible argument for the operating model security teams have wanted all along: product defaults decided deliberately, designs reviewed before build, classes of weakness engineered out rather than patched around, and honesty in public reporting. Signed or not, that is just what a mature engineering organization looks like.
The design-phase share of that work, the reviews, the threat models, the decisions with names attached, is what Alvor's Secure by Design module runs as a governed workflow, so the practice survives contact with a real roadmap.