Secure-by-Design has an Incentive Problem

In my last blog post, I argued that we don’t need more innovation invention to fix the broken state of SaaS and cloud security that Patrick Opet’s open letter was calling out. Instead, I said that what we need are different priorities. The conversations it triggered basically boiled down to this: if we already know what good looks like, why aren’t more vendors and enterprises doing it?

<Slight aside>On LinkedIn, Mike Schwartz called me out for saying we don’t need innovation, which is fair. He pointed out that what I was calling out was not needing more invention (of new tech or standards), but innovating on just getting people to use a lot of what we already have. Thankfully, that lines up with where the rest of this post is going<End aside>

The answer, unfortunately, is as straightforward as it is challenging: the incentives are all wrong.

Secure-by-design isn’t failing because the right standards, technology, or architectures don’t exist. It’s failing because there is no systemic reason to prioritize it – neither for the people building software, nor for those buying it. In fact, one could argue that today’s ecosystem actually discourages secure-by-design thinking. Vendors end up optimizing for roadmap velocity, not resilience. Enterprise buyers meanwhile are optimizing for feature parity and price, not control integrity. Security teams are told to meet deadlines instead of challenging system design. And compliance overrides capability as the default benchmark for “good enough.”

Compliance Is Treated as the Ceiling instead of the Floor

As many discussions at the recently concluded Identiverse conference made clear, compliance does result in security, but the kind that’s seemingly frozen in time: narrowly scoped, backward-looking, and audit-centric. Compliance-driven security doesn’t adapt as threats evolve. It doesn’t incentivize secure architectures. And it certainly doesn’t reward proactive, defense-in-depth investments like the ones being called for: session integrity, token binding, or real-time access evaluation.

This is what makes Patrick Opet’s open letter so relevant. Despite my reservations with where some of the blame was laid, what it clearly did was call out the need for all of us to stop settling for security theater, and to start building systems that are actually resilient to our ever-evolving threat landscape.

The hard truth is that we can’t expect (security) people to just do the right thing (cue the philosopher in my ear saying “duh!”). We need to create incentives for doing the right thing.

Secure-by-design isn’t rocket science, but it does require effort. It requires time, architectural rethink, cross-functional coordination, and long-term investment. Unfortunately in today’s landscape, it is hard to find places where that is rewarded (though I have seen some examples of teams really trying).

So if we want more secure-by-design adoption, we need to fix the incentive structures that govern behavior, both for vendors as well as buyers.

What A Good Incentive Structure Could Look Like

1. Shift Liability for Insecure Defaults: Right now, when SaaS vendors ship insecure implementations of OAuth or rely on fragile session management, it is the customer who typically pays the price in the event of a breach. Introducing clearer, shared liability standards – especially in cases of negligence or insecure-by-default configurations – would force vendors to take greater ownership of security posture, not just feature completeness. And I say this as someone who’s spent his life mostly on the vendor side of the equation.
2. Make Secure Architectures a Market Advantage: Security is often invisible in the buying process. That has to change. Procurement teams can start by asking tougher/deeper questions in RFPs. Go beyond “Do you support SSO?” and “Do you implement OAuth”, and start asking “How do you manage token lifecycle and session state?” and “are you enforcing DPoP or Mutual TLS?”. Independent benchmarking (think energy efficiency ratings or credit scores) could create a public, competitive metric for software security maturity. As a security industry, we need to make it much, much easier for buyers to do comparative evaluations.
3. Reward Security Investments with Lower Cyber Risk Premiums: Cyber insurance is a rapidly growing space. Providers are already building models to assess risk posture, and are in a perfect position to reward vendors and buyers who implement secure-by-design principles with lower premiums or higher coverage ceilings. This is already done in other domains (drivers that have done a defensive driving course are cheaper to insure). So why can’t we do the same for software with hardened session controls? Of course, the previous point about creating benchmarks and making comparisons easier become relevant here.
4. Measure the Right Things at the Board Level: How many posts have we seen about security and fraud reduction needing to become a board level priority. But it has to be done correctly. If the only metric security leaders are reporting to the board is “number of passed audits,” then secure-by-design will never get the visibility or funding it needs. We need to elevate identity posture, architectural maturity, and integration integrity to the same level as SLAs and NPS. Security isn’t just a function of the CISO. It’s a strategic business risk. And boards should treat it accordingly, giving CISOs the support they need.
5. Embed Security Into Corporate Culture: This one’s less about structure and more about mindset. Just as accessibility and sustainability are becoming table stakes in modern product development (sometimes through regulation), secure-by-design needs the same kind of internal advocacy. That means giving product managers and engineers the time, training, and tooling to make security a design decision, and not something relegated to a post-launch cleanup effort. It means moving security left and up the value chain.

This Isn’t About Blame. It’s About Incentive Design.

The clear need of the hour is to realign the system so that secure-by-design becomes the default outcome of doing good business. That means rethinking procurement, regulation, insurance, and organizational measurement. This is asking more of both enterprise buyers and vendors, but also giving them a reason to invest.

The technical playbook already exists. The missing ingredient is the will to change incentives. Until we fix that, we’ll keep pretending that compliance is enough, even as the cracks widen. We must stop rewarding checkbox security. Let’s start building systems that are actually built to withstand the world we live in.