CISA’s Secure by Design pledge started small, 68 software manufacturers signed on in May 2024. By CISA’s count in June 2026, that list had grown to 367 signers, and the agency used its August 10, 2026 announcement to spotlight fresh commitments from leading technology providers. Good news, worth tracking. But buried in the pledge itself is a distinction I keep seeing vendor evaluations flatten into one question. Two of the pledge’s seven goals are about what ships turned on: no default passwords, MFA enabled out of the box. A separate goal is about measurably reducing entire classes of vulnerability through how the product gets engineered in the first place. CISA didn’t group those together, and for good reason. They fail differently, they get fixed differently, and if your architecture board is scoring them as a single “security reviewed: yes” checkbox, you’re missing half the picture.
Same Device, Two Different Failures
The clearest example this year isn’t a SaaS breach, it’s fuel storage. In June 2026, CISA, the FBI, NSA, and five other federal agencies put out a joint advisory after catching attackers actively targeting internet-exposed Automatic Tank Gauge systems, the kind used across energy, transportation, and food distribution. The advisory named two categories of flaws sitting in the same devices. One: hardcoded credentials and SQL injection paths baked directly into the software. Two: default passwords left unchanged on management interfaces reachable from the open internet. The first is a design failure, something a threat model or a decent secure coding standard should have caught before the product ever shipped. The second is a default failure, a decision about what the box does the moment a customer plugs it in. You fix the design flaw by re-engineering the product. You fix the default by changing a setting nobody warned the customer was dangerous to leave alone. Two very different remediation paths, same CVE writeup.
Cloud Accounts Tell the Same Story, With Better Documentation
You don’t need an obscure ICS device to see this split, it shows up in mainstream cloud environments too, just with cleaner numbers attached. Per Verizon’s 2026 Data Breach Investigations Report, only 23 percent of third-party organizations fully remediated missing or misconfigured MFA on cloud accounts. For weak passwords and permission misconfigurations, resolving half of all findings took close to eight months. None of that is an architecture problem in the design sense, the identity architecture underneath is usually fine, MFA exists, RBAC exists, the platform supports least privilege well enough. What fails is what shipped turned on, what got left off, and how long it took anyone to notice. That’s a defaults problem. It’s also the one most RFP security questionnaires are worst at catching, because “does your product support MFA” gets a clean yes from a vendor whose console still ships with MFA off by default.
Score Them as Two Line Items
The fix, practically speaking, is to stop asking vendors one security question and start asking two. The evidence for each is different, and one of them can’t be taken on the vendor’s word alone. Design-time questions belong in the RFP and in the ARB’s blast-radius review: what vulnerability classes has the product structurally eliminated, is that enforced by the framework or left to individual developer discipline, what does the SDLC and threat-modeling practice actually look like. Answering those well requires a paper trail. That’s exactly the gap the principles-to-implications scoring approach was built to close, turning a vague “secure development, yes” checkbox into a weighted, evidence-based line item instead.
Default-configuration questions need a different kind of proof, and it’s not one a whitepaper can supply. You have to log into the actual pilot instance and go look. Is MFA on before anyone touches a setting. Is there a default credential sitting in the install guide. Is the admin interface reachable from outside the customer’s network out of the box. This is exactly why vendor risk review can’t sit at the tail end of procurement, right before signature, when there’s no leverage left to demand a hardened build. It has to happen at intake, against something actually running, which is the same case I made in moving vendor risk assessment into architecture review rather than treating it as a procurement afterthought.
Both scores should land as separate, permanent attributes on the vendor and application record in your EAM system, not a single pass or fail gate that gets forgotten the week after go-live. A product that’s secure by design but shipped insecure by default is a configuration-management problem, fixable with a hardening baseline and a recurring audit. A product that ships hardened defaults on top of a weak design is a different animal entirely, a liability sitting quietly until someone under deadline pressure flips one setting and discovers there was never any architecture underneath to contain the blast radius. Fund the fix for the first one. Don’t buy the second one at all, no matter how clean the default configuration screenshot looked in the demo.