Secure by Design is joint guidance, led by CISA with international partners, urging software makers to build security into products rather than push it onto customers. Its three principles are taking ownership of customer security outcomes, embracing radical transparency and accountability, and leading from the top. A small fintech can apply each in practical ways.
What the guidance is
CISA's page describes the document "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software," initially published in April 2023 and updated on October 25, 2023 with expanded principles and guidance and eight additional international agency co-sealers. It urges software manufacturers to take the steps needed to ship products that are secure by design, and says manufacturers must be able to compete on the basis of security.
It is aimed at software manufacturers. A fintech that ships a product to customers or banks can read it as a roadmap for what buyers may increasingly expect. It is guidance, not a legal requirement for a startup, and nothing here is legal advice.
The three principles in plain words
| Principle | What it means for a small fintech | A concrete first step |
|---|---|---|
| Take ownership of customer security outcomes | Do not leave customers to harden your product | Ship safe defaults, such as MFA available and scoped API keys |
| Embrace radical transparency and accountability | Be open about vulnerabilities and fixes | Publish a way to report vulnerabilities and give honest advisories |
| Lead from the top | Leadership treats security as a business goal | A named executive owner and a regular review |
What to do with each
Ownership. Look at your product through a customer's eyes. Which security features are off by default? Which require an expert to configure? For a payments API, that might mean restricted keys, webhook signing, and clear guidance on separating test and live credentials. Moving safe behavior into defaults reduces the burden on customers.
Transparency. Customers and partners value accurate information. Maintain a security contact, respond to reports, and publish notes when you fix a flaw that affects them. Share an SBOM or a dependency summary when asked, and describe your controls precisely rather than loosely.
Leadership. A control that nobody senior watches decays. Put a short security review in your monthly leadership meeting, with a few numbers: open critical vulnerabilities, time to fix, access reviews done, and incidents.
Tie it to engineering habits
The ideas land through ordinary controls we cover elsewhere: required reviews on payment code, short lived credentials in the pipeline, a dependency review check on every pull request, and per environment secrets. Each shows that security is built into how the product is made.
A one quarter plan
- Write down three safe defaults your product lacks and fix one.
- Publish a vulnerability reporting address and an internal owner for incoming reports.
- Produce a dependency inventory for your main service and review it with engineering leadership.
- Add a one page security section to your monthly leadership review.
- Run a customer facing review of your documentation: could a new customer configure the product securely from it?
Avoid overclaiming
Do not call your product "secure by design" in marketing unless you can show the practices behind it. The guidance is about demonstrating commitment, and that includes being accurate. Describe what you do, with dates, and avoid claims about certifications or attestations you do not hold.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, policies and gates, and compliance evidence automation can support the transparency and engineering habits above. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is Secure by Design a legal requirement?
The CISA page presents it as guidance for software manufacturers. Check with your own advisers about obligations that apply to you.
What is the simplest place to start?
Pick one insecure default in your product and change it, then document the change.
Sources
Last reviewed: 19 October 2026.
