- 01The pledge's seven goals are concrete and measurable — which is exactly what makes them hard. Vendors cannot claim partial credit; either MFA is the default or it is not.
- 02MFA-by-default and default-passwords-eliminated are the two highest-cost goals because they require touching every product, every distribution channel, and every customer onboarding flow.
- 03Reducing CVE classes is the only goal that requires investment in language and framework choices — memory-safe languages, parameterized data layers, secure-by-default frameworks.
- 04Customer security telemetry by default — exportable logs, integrity-protected — is the goal most signers underestimate. It requires a real product investment, not just a doc page.
- 05The honest pledge program publishes its roadmap with deadlines per goal, per product, per quarter. Anything else is a marketing sentence.
CISA's Secure by Design pledge has gathered hundreds of corporate signatures. The seven goals — MFA by default, default passwords eliminated, reduce CVE classes, patch installation by default, vulnerability disclosure policy, CVE accuracy, and customer security telemetry — are concrete and reasonable. Implementing them across a real product portfolio is multi-year engineering work that touches every product team, not just the security organization.
This piece is the implementation plan we run for product-security organizations who have signed the pledge and now have to deliver on it. It is written for the head of product security who has to brief the CEO on cost, and the engineering manager who has to wedge the changes into the existing roadmap.
Why the pledge is structurally useful even if you do not sign it.
The pledge's seven goals are the cleanest articulation of product-security baselines published this decade. Even if your legal team is allergic to a public commitment, run the program internally against the pledge's text. The customer questionnaire responses get easier, the product requirements get sharper, and the CISO conversation with the CEO has language that travels.
The seven goals — in implementation cost order
Below are the seven goals re-ordered by the engineering effort we have measured across signer engagements. The order matters: tackling them in published order ('MFA first') is right; tackling them in alphabetical order is the most common derailment.
/PLEDGE_GOALS · IMPLEMENTATION_COST
| # | Goal | Effort | Where it hurts most |
|---|---|---|---|
| 1 | MFA by default (admin paths) | High | Every product onboarding flow + customer comms |
| 2 | Default passwords eliminated | High | Every product, every distribution channel, OEM partners |
| 3 | Reduce CVE classes | Very High | Language / framework migrations; multi-year |
| 4 | Patch installation by default | Medium | Customer change-management resistance |
| 5 | Customer security telemetry | Medium-High | Real product investment; not a doc update |
| 6 | Vulnerability disclosure policy | Low-Medium | Operational scaling of triage |
| 7 | CVE accuracy | Medium | Coordinated disclosure team capacity |
Goal #1 — MFA by default (where most programs underestimate)
The pledge does not ask for MFA to be available; it asks for MFA to be the default. That distinction is the engineering work. Every product's onboarding flow must change so that a new admin account, on first login, is required to enroll a phishing-resistant factor. The migration of existing admins to MFA is a separate (and larger) project, with customer-comms implications.
- 01Inventory every administrative entry point across every product. Most enterprises find 30–50% more entry points than the product team listed.
- 02Define 'phishing-resistant' as WebAuthn / passkey or smart card. Avoid SMS / TOTP as default; allow them only as fallback.
- 03Stage the change: new accounts first (cheap), then dormant accounts (warned and forced), then active accounts (campaign with deadline).
- 04Customer comms: 90 days notice for active-account migration, with deadline, with a CSAT-protective fallback path.
Goal #3 — Reducing CVE classes (the multi-year goal)
Reducing CVE classes is the goal that touches the deepest part of the engineering organization. The pledge does not specify language choice; the implementation almost always implies one. Below is the pattern we recommend for new code and the migration plan for legacy code.
Memory-safe languages cut a category of CVEs, not all CVEs.
Migrating to Rust eliminates buffer overflows and use-after-free; it does not eliminate logic flaws, authorization bugs, or supply-chain compromises. The CVE-class reduction goal is per-class accounting. Track it that way, and the language migration narrative survives a CEO who asks 'why are we still getting CVEs?' three years in.
/CVE_REDUCTION · LANGUAGE_PLAN
# A defensible CVE-reduction plan, abbreviated.
new_code:
rule: "All new services in memory-safe languages."
preferred: [Rust, Go, Kotlin, Swift, TypeScript-with-strict-null]
permitted_with_review: [Java, C#]
prohibited: [C, C++, Python-without-typing]
legacy_code:
C_Cpp_inventory:
audit: quarterly
annual_migration_target: 15% # of LOC, by criticality weight
sandbox_unmigrated: true # WASM, seccomp, capability sandbox
injection_classes:
sql: "Parameterized only. No string interpolation."
cmd: "Library-mediated only. No shell strings."
template: "Auto-escape on; sandbox untrusted templates."
metrics:
target: "30% reduction in CVE assignments per LOC, year over year"
Goal #5 — Customer security telemetry (the underestimated lift)
The pledge asks vendors to provide customers with the security-relevant logs needed to investigate intrusions. In practice this means: structured logs, integrity-protected, exportable in real time, with a documented schema, retention guarantees, and customer-controlled redaction for PII. This is a real product investment — usually 6–12 engineer-months per major product.
- 01Schema: published, versioned, OpenTelemetry-aligned where possible
- 02Coverage: authentication events, configuration changes, privilege grants, data access at the boundary
- 03Integrity: signed batches; tamper-evident; verifiable by the customer
- 04Export: real-time streaming (HTTP, Kafka, S3) — not 'available on request'
- 05Redaction: customer-controlled for PII; never silently performed by the vendor
The honest pledge roadmap — published, dated, owned
The single most useful pledge artifact a vendor can publish is a per-goal, per-product, per-quarter roadmap. Below is the format we recommend. Customers can hold the vendor to it; the vendor can hold engineering teams to it; the security organization stops being the bad cop because the roadmap is the bad cop.
/PUBLIC_ROADMAP · TEMPLATE
| Goal | Product | Default-on date | Owner |
|---|---|---|---|
| MFA by default (admin) | Product A | 2026-Q3 | Eng Mgr A |
| MFA by default (admin) | Product B | 2026-Q4 | Eng Mgr B |
| Default passwords eliminated | Product A | 2026-Q2 (done) | Eng Mgr A |
| Customer telemetry export (v1) | Product B | 2027-Q1 | Eng Mgr B |
| VEX feed (CVE accuracy) | All products | 2026-Q4 | Product Sec Lead |
Five KPIs the board and customers should both see
/PLEDGE_KPIS
| KPI | Target | What it proves |
|---|---|---|
| % of admin paths MFA-by-default | 100% | Goal #1 is operational, not aspirational |
| % of products shipped with no default password | 100% | Goal #2 is end-to-end |
| CVE assignments per kLOC, YoY trend | Down 20%+ | Goal #3 is producing results |
| Days from VDP report to triage | ≤ 3 | Goal #6 is staffed appropriately |
| VEX feed coverage of issued CVEs | 100% | Goal #7 is automated |
A 12-month plan to turn the pledge into a program
- 01Q1 — Inventory admin paths. Land MFA-by-default for new accounts in the top three products. Publish the public roadmap. Stand up VDP triage capacity.
- 02Q2 — Eliminate default passwords across all distributions. Begin customer-telemetry product investment. Land CVE-class reduction plan in engineering OKRs.
- 03Q3 — MFA-by-default migration for active admins (with 90-day customer comms). Publish first VEX feed. Begin language-migration first wave.
- 04Q4 — Customer-telemetry v1 in flagship product. Publish year-one pledge progress report against the five KPIs. Re-baseline roadmap for year two.
Monday morning — the test for whether the pledge is real in your org.
Open your product onboarding flow as a brand-new admin user. Are you forced — not invited — to enroll a phishing-resistant factor before performing any administrative action? If not, the pledge is a marketing sentence in your organization. Open one engineering ticket today to fix that one product. Use it as the wedge to fund the program properly.
- ▸Sign up as a fresh admin in your own product
- ▸Test whether MFA enrollment is mandatory or optional
- ▸Time how long until you can perform a destructive action without MFA
- ▸If > 0 seconds, file the ticket; the pledge is the cover story for funding
Closing — the pledge is a roadmap, not a press release
Vendors that treat the Secure by Design pledge as a published, dated, owned roadmap end up with safer products and easier customer conversations. Vendors that treat it as a one-page sentence end up with the worst of both worlds — public commitment, no engineering progress, eventual CISA call. The seven goals are the right list. Stage them, publish the dates, hold the line, measure five KPIs. The work is hard but bounded. The reward is a product portfolio that does not need a security organization to apologize for it.