CISA Secure by Design Pledge: Should Your SaaS Company Sign?

Short answer: The CISA Secure by Design pledge is a voluntary, non-binding commitment for enterprise software makers to make a good-faith effort on seven security goals and show measurable progress within one year of signing. For an SMB SaaS or HealthTech vendor, signing makes sense when most of the evidence already exists in your SOC 2, ISO 27001 or HIPAA program.

Related guides:

• Secure by design principles for product teams
• Vulnerability disclosure
• Phishing-resistant MFA

Key takeaways

• CISA announced the first pledge commitments on May 8, 2024. The pledge is voluntary and CISA does not enforce or verify adherence.
• It covers enterprise software, including on-premises software, cloud services and SaaS.
• The seven goals cover MFA, default passwords, classes of vulnerability, security patches, a vulnerability disclosure policy, CVE reporting and evidence of intrusions.
• Most goals reuse SOC 2, ISO 27001 or HIPAA evidence. The new work is usually the disclosure policy, CVE practice and a public write-up.
• Plan the year per goal and decide early where you will publish progress.

---

What is the CISA Secure by Design pledge?

It is a public, voluntary commitment by a software manufacturer to work toward seven product security goals for one year and then document the results. According to the CISA pledge page, "This pledge is voluntary and not legally binding," and it focuses on enterprise software products and services, including on-premises software, cloud services and software as a service. Physical products such as IoT devices and consumer products are not in scope, although companies may choose to show progress there too.

CISA's 2024 Year in Review records that leading technology companies committed to the pledge on May 8, 2024, and that more than 250 companies had signed by the time that review was published.

The pledge is about the product you ship, not your internal IT, which is the key difference from SOC 2 or ISO 27001.

What are the seven Secure by Design pledge goals?

The seven goals are MFA, default passwords, reducing entire classes of vulnerability, security patches, a vulnerability disclosure policy, CVE reporting and evidence of intrusions, each summarized below from the official pledge text.

#	Goal	What the pledge asks for, in short
1	Multi-factor authentication	Measurably increase MFA use across your products, for customers and administrators, with phishing-resistant MFA preferred
2	Default passwords	Measurably reduce universally shared default passwords, so only the customer holds credentials after provisioning
3	Reducing entire classes of vulnerability	Pick one or more classes, such as SQL injection, cross-site scripting or memory safety issues, and reduce them at scale
4	Security patches	Make it easier for customers to install patches, for example through automatic updates. For cloud and SaaS, the vendor carries the patching burden
5	Vulnerability disclosure policy	Publish a policy that authorizes good-faith testing, commits not to pursue legal action against good-faith researchers, gives a reporting channel and allows coordinated public disclosure
6	CVEs	Include accurate CWE and CPE fields in CVE records and issue CVEs promptly for at least critical or high-impact vulnerabilities that need customer action or are actively exploited
7	Evidence of intrusions	Give customers logs and artifacts, such as configuration, identity and data-access logs, to detect and investigate intrusions, and document log retention

The pledge offers example approaches and leaves the metric to you.

What is the status of the pledge as of October 2026?

As of October 2026, the pledge page still publishes the full pledge, describes "hundreds of companies who have signed the pledge," and links to a progress reports page where signers' published updates are collected. We could not find a CISA statement announcing that the pledge has closed or changed, and neither page shows a last-updated date, so check the pages directly before you sign.

CISA states that it "does not enforce nor verify adherence to the pledge," and that a listing is not an endorsement or attestation of product security. Treat the pledge as a public roadmap you are accountable for, not a certification.

Should an SMB SaaS or HealthTech vendor sign?

Sign if you sell enterprise software, already run a SOC 2, ISO 27001 or HIPAA program, and can name an owner for each goal. Wait if you cannot yet commit engineering time to the product-level goals.

Work through these in order:

1. Do you ship enterprise software, cloud services or SaaS? If you only sell physical or consumer products, it is not aimed at you.
2. Do you already run a compliance program? With SOC 2, ISO 27001 or documented HIPAA safeguards, much of the evidence exists. If not, build that first.
3. Can you name an owner per goal? CVE reporting and vulnerability classes need engineering time.
4. Will you publish an honest update in 12 months? If yes, sign. If not, adopt the goals internally and sign later.

For HealthTech vendors, in our experience a public progress report answers some hospital questionnaire items on MFA, patching and logging early. It does not replace HIPAA obligations.

How do the goals map to SOC 2, ISO 27001 and HIPAA evidence?

Most goals reuse evidence you already collect, but the pledge measures the product your customers use, not only internal systems.

Pledge goal	Evidence you likely already have	What is new for the pledge
MFA	SOC 2 logical access evidence, ISO 27001 secure authentication controls, HIPAA person or entity authentication	Customer MFA enrollment rate in your product, tracked over time
Default passwords	Hardening standards and onboarding procedures	Proof that no shared default credential ships to customers
Vulnerability classes	Secure development policy, code scanning and pen test results	A chosen class, a baseline count and a reduction approach
Security patches	Patch management records and scanning cadence	Customer-facing patch timeliness, or a statement that you patch SaaS for customers
Disclosure policy	Incident and vulnerability management policies	A public policy with safe harbor language
CVEs	Vulnerability tracking and severity ratings	A CVE process with CWE and CPE fields
Evidence of intrusions	Logging and monitoring controls, HIPAA audit controls	Customer-accessible logs and a published retention policy

Your audit evidence proves the control exists. The pledge asks you to turn it into a customer-facing metric. An SBOM is not one of the seven goals, but it helps with goals 3 and 6 because it tells you which components and versions are exposed.

What does a 12-month plan per goal look like?

Split the year into four quarters: baseline, build, measure and publish.

Goal	Months 1 to 3: baseline	Months 4 to 6: build	Months 7 to 9: measure	Months 10 to 12: publish
MFA	Record customer and admin MFA rates	Add prompts and phishing-resistant options	Track monthly enrollment	Report before and after rates
Default passwords	Inventory credentials set at provisioning	Replace shared defaults with per-customer setup	Verify in a test environment	Describe the change
Vulnerability classes	Pick one class, count findings	Adopt safer frameworks for that class	Track findings per release	Report the trend
Security patches	Document how fixes reach customers	Automate customer patch steps	Measure fix-to-deploy time	Publish the process
Disclosure policy	Draft scope, channel, safe harbor	Publish policy and contact	Log reports and response times	Summarize the program
CVEs	Decide how you will request CVEs	Write the triage and CVE workflow	Use it for qualifying issues	Describe the practice
Evidence of intrusions	List logs customers can access	Expose audit logs, document retention	Confirm customers can use them	Publish log documentation

Set the baseline first, or you will have no "before" number. The disclosure policy is usually the quickest goal to complete.

How do you publish a pledge progress report?

Publish a page on your site, such as your trust center, stating each goal, what you did and the result. The pledge asks signers to publicly document how measurable progress was achieved. Where progress was not made, the pledge asks you to share with CISA how you worked toward the goal and the challenges you faced, and it encourages publishing that too.

A simple structure:

• Summary: date signed and a one-line status per goal.
• Per goal: baseline, action taken, current metric and next step.
• Honest gaps: goals that slipped, why, and a new date.
• Contacts: your disclosure policy link and security contact.

Keep published numbers consistent with your audit evidence.

How SecureSlate helps

In SecureSlate, the pledge is set up as a custom framework with seven custom controls, one per goal. Multi-framework control mapping links each one to your SOC 2, ISO 27001 and HIPAA controls, so one set of evidence serves both.

• Agentless read-only cloud integrations and the device agent collect access, logging and configuration evidence.
• Code security and secrets detection support the vulnerability class and default credential goals.
• Trust center publishes your progress report and disclosure policy link.
• Security questionnaire automation reuses pledge answers in customer reviews.

Start your free SecureSlate trial

FAQ

Is the CISA Secure by Design pledge mandatory?

No. CISA states the pledge is voluntary and not legally binding. It is a public commitment, not a regulation or certification.

Can a small SaaS company sign the pledge?

The pledge targets enterprise software makers, including SaaS, and the text does not state a minimum company size. Check the pledge page for the current signing process.

What happens if we miss a goal after one year?

The pledge asks you to share with CISA how you worked toward the goal and the challenges you faced. Customers may read your report, so be candid.

Does signing the pledge help with SOC 2 or HIPAA?

Not directly, because it is not an audit framework. The work it drives, such as stronger MFA and logging, also strengthens audit evidence.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.