The quiet failure mode of enterprise security
If you have ever inherited a fleet of appliances, SaaS connectors, or “enterprise platforms,” you know this pattern:
- Product ships with convenience defaults
- Customer security team spends months hardening
- Some controls cannot be enabled without breaking supported configs
- A breach write-up later says “misconfiguration”
- Everyone pretends the root cause started in the customer’s change window
Sometimes the customer really did fail. Often the product made safe operation the hard path and unsafe operation the default path. That is not a fair division of labor.
CISA’s Secure by Design work exists to rebalance that division.
Primary sources worth reading directly:
- Hub: https://www.cisa.gov/securebydesign
- Joint guide PDF (Oct 2023 update): Secure by Design — Shifting the Balance of Cybersecurity Risk
- Resource page: Secure-by-Design resource
What CISA is actually asking manufacturers to do
The guide’s product security principles are not mysterious:
- Take ownership of customer security outcomes
- Embrace radical transparency and accountability
- Lead from the top
Principle 1 is the one I quote in vendor meetings. CISA’s language is direct: the burden of security should not fall solely on the customer; manufacturers should evolve products so customers get safer outcomes without heroic configuration.
That is a different moral economy from “we provide the locks; you figure out which doors exist.”
Ownership of outcomes vs ownership of blame
In operations, “ownership” has to mean design choices, not apology statements after incidents.
Concrete examples of manufacturer ownership:
- No default passwords on anything that can reach a network
- Secure defaults that favor least privilege and encryption on
- MFA that is normal, not a premium SKU buried behind professional services
- Memory-safe languages / classes of bug elimination where practical, with public discussion of classes of CVEs fixed at root
- Hardening guides that shrink over time because defaults improved—not expand into novels
- SBOMs and vulnerability response that assume customers will be hit by your dependency failures
- Self-attestations against SSDF-style practices so buyers can compare something more than marketing adjectives
CISA’s guide goes into tactics like threat modeling that includes how products are attacked in the wild, field testing, reducing reliance on customer hardening, publishing patterns from past vulnerabilities, and maintaining SBOMs. If you only remember one theme: make the secure path the easy path.
Why this hits data protection work specifically
Privacy and data protection teams live with manufacturer failure modes daily:
- Logging that captures personal data by default and offers redaction as a paid add-on
- Admin consoles that cannot enforce phishing-resistant MFA for all privileged roles
- “Analytics” toggles that share data broadly unless a customer finds page 19 of a PDF
- Encryption features that exist but are off unless you buy a higher tier
- Retention controls that cannot meet policy without custom engineering
When a product forces weak defaults around personal information, the downstream DPIA becomes a negotiation with a vendor roadmap. Secure by Design is how you argue that the control should have been upstream.
Secure by Design is also Secure by Default
People sometimes separate the phrases. In practice they travel together.
- By design: security is a first-order product requirement in architecture and development, not a pre-GA checklist
- By default: the out-of-box state is safe for a realistic deployment, not a lab demo
A product can have elegant security architecture and still ship with open management interfaces and sprawling privileges. That fails the customer-outcome test.
What buyers should demand (usable in RFPs)
I do not need vendors to recite CISA slogans. I need artifacts:
Evidence pack
- Threat models for the product (even high-level)
- Default configuration posture and what is on/off at install
- MFA/SSO support matrix for all privileged paths
- Vulnerability disclosure policy and mean time characteristics they will commit to publicly
- SBOM delivery method and update cadence
- History of eliminating a class of issues (not only patching instance #47)
- Clear statement of customer responsibilities vs manufacturer responsibilities
Contract hooks
- Security defaults documented as warranted baseline
- Notification timelines for critical issues
- Right to receive SBOMs and attestation artifacts
- Roadmap commitments for known insecure patterns (for example, retiring password-only admin access)
Operational tests
- Install in a lab without the sales engineer’s “recommended hardening script.” Observe what is exposed.
- Attempt to run it safely with only documented defaults. Time the delta. That delta is your hidden TCO.
Where CISSP thinking aligns
This maps cleanly to:
- Security architecture and engineering — secure defaults, least privilege, defense in depth baked in
- Supply chain risk — manufacturer quality as third-party risk
- Governance — board-level product security accountability (CISA’s “lead from the top”)
- Software development security — SSDF-aligned practices, threat modeling, memory safety strategies
The exam point of view emphasizes building security in. CISA’s contribution is political economy: who pays the residual risk when security was not built in—customer ops, or manufacturer product management?
Manufacturer pushback you will hear (and how I answer)
“Every environment is different.” True. Defaults still shouldn’t be trivially exploitable. Complexity is not an excuse for universal weak posture.
“Hardening guides are industry standard.” Guides are fine as layered help. They are a smell when they are required to reach a minimum bar.
“We need usability for first-time setup.” Usability and secure defaults are a design problem, not a mutually exclusive pair. Out-of-box open admin with a well-known password is not usability; it is negligence with a welcome wizard.
“Enterprise customers demand flexibility.” Flexibility can exist behind explicit, authenticated choices—not as silent insecurity.
Internal IT is a manufacturer too
This is the part practitioners dodge. If your team ships internal platforms, APIs, machine images, or analytics tools to the rest of the company, you are in the manufacturer role.
Apply the same principles inward:
- Secure defaults on internal apps
- No shared break-glass passwords in wikis
- AuthN/AuthZ patterns that product teams inherit easily
- Golden paths that are safer than shadow IT paths
Secure by Design fails if security teams only externalize it to vendors while internal tools remain “temporary” for three years.
Operational friction inside customer organizations
Even good Secure by Design products create work:
- Migrating off insecure legacy modes
- Rebuilding install playbooks that assumed open defaults
- Retraining support staff who used insecure convenience features
- Updating detection content when attack surface shrinks or moves
Do that work gladly. It is still cheaper than eternal compensating controls.
Also friction: marketing will claim “Secure by Design” without evidence. Your job is to ask for the artifacts listed above and to walk away when the answer is a logo on a conference booth.
A practical scorecard for the next vendor cycle
Rate each critical vendor 0–2 on:
- Secure defaults at install
- Privileged access hardening without heroics
- Transparency (SBOMs, vuln history analysis, public commitments)
- Ability to eliminate classes of issues
- Executive ownership signals (not only a PE email alias)
- Alignment of contract language with security outcomes
Use the score in award decisions. If security cannot affect award, you are doing theater.
What “good” looks like a year after you take this seriously
- Hardening guide page counts drop for strategic products
- Fewer emergency exceptions for “cannot enable MFA”
- Vendor risk reviews include design evidence, not only pen-test PDFs
- Internal platform teams are measured on secure defaults adoption
- Incident retros distinguish customer error from predictable manufacturer debt
Sources
- CISA Secure by Design hub: https://www.cisa.gov/securebydesign
- Joint guide PDF: https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf
- CISA resource entry (principles summary and update context): https://www.cisa.gov/resources-tools/resources/secure-by-design
Actionable takeaway
CISA Secure by Design is a responsibility shift: manufacturers own security outcomes, not just feature delivery, and customers should buy—and build—accordingly. The three principles (ownership, transparency, leadership) only matter when they change defaults, roadmaps, contracts, and internal platform standards. Stop celebrating heroic hardening as the high point of maturity. The high point is a product that does not need heroics to be safe.