Making Security an Enabler

For a lot of product and engineering teams, security has a branding problem.

Too often, it shows up at the end of the process as the function that says no.

No, that architecture won’t pass review.
No, that workflow isn’t compliant.
No, you can’t ship it that way.

The problem isn’t that the risks are imaginary. Most of the time, they aren’t. The problem is what happens next: teams learn to avoid security for as long as possible. They treat security review like a tollbooth at the end of the road instead of a design partnership at the beginning.

That dynamic is broken.

It also explains where one of the phrases I use most often comes from: making security an enabler.

The moment it clicked

Early in my career at RBC, we were working on Android Pay during the host card emulation era. That created a real design constraint: payment tokenization had to work without relying on a hardware secure element on the device.

In other words, the clean textbook answer wasn’t available.

The easy security response would have been simple: don’t ship it. If keys can’t live in a hardware-backed element, then the architecture isn’t strong enough.

Instead, I was lucky enough to work with excellent security partners. A security consultant sat down with us and worked through the problem. Together, we designed a scheme that used session-based keys for limited transactions rather than storing the master key on device. Users had to refresh keys periodically, and offline usage was constrained so the blast radius stayed small.

It wasn’t the idealized architecture you would draw on a whiteboard with no product constraints.

But it was secure enough for the risk model, it protected customers, and it let us ship.

That was the moment it clicked for me: great security doesn’t lower the bar. It helps teams clear it.

What good security sounds like

That lesson stayed with me through payments, confidential computing at Fortanix, and now Azure.

The best security work I’ve been part of rarely starts with a flat no. It starts with a different question:

How do we achieve the goal safely?

That shift sounds small, but it changes everything.

“You can’t store that data there” becomes “here’s a pattern that protects the data and still meets your latency requirements.”
“That agent can’t call external APIs” becomes “here’s how to establish stronger identity, constrain authorization, and make the invocation auditable.”
“No” becomes “yes, with guardrails.”

That’s the difference between security as an obstacle and security as an enabling function.

Why this matters

When security teams only provide vetoes, the organization adapts in exactly the wrong way. Teams delay engagement. They work around review. They hide complexity until late in the cycle. Risk doesn’t go away; it just becomes less visible.

That is not a stronger security posture. It’s a weaker one.

The best security teams understand that their job is not just to identify landmines. It’s to help the organization move through the field without stepping on one.

That means being rigorous about risk while still offering implementable paths forward.

Not every answer should be yes. Some things really should not ship. But if security becomes known as the department of no, it should not be surprised when the rest of the company learns to route around it.