The day “access” stopped meaning “login” and started meaning “authorization”

A security leader I respect told me something a while back that I think about more than I should. He said, “We did everything right. And we still couldn’t answer the question.”                              

The question wasn’t exotic. It wasn’t a nation-state scenario.    

It was the kind of thing that shows up in the real world, in the middle of a normal week:    

A production issue hit. Customers were impacted. The team did what teams do when the pressure is real. They pulled in the right engineer, who connected and authenticated into their production tenants. No drama. No chaos. No cowboy behavior.    

Later, when the incident review started, the conversation shifted from “how did we fix it” to “who had access to what while this was happening.”    

That’s where things got uncomfortable.    

Not because the company lacked an identity provider. Not because MFA was missing. Not because the network was wide open. They had those layers in place. They had a decent story for who could log in and how systems were reached. What they didn’t have was a clean story for what people could actually do once they were in.    

And if you’ve ever sat through an audit, an incident review or a board-level conversation after something goes sideways, you know exactly where this goes. You end up piecing together a narrative from logs, tickets, approvals that happened in someone’s inbox, screenshots someone saved “just in case” and a handful of chat messages.    

Most teams don’t set out to run production access that way. They just inherit it. It accumulates through exceptions and workarounds and “temporary” privileges that become permanent because nobody wants to be the person who blocks the next incident fix.    

This is the moment where people realize they’ve been using the word “access” too loosely. They’ve been treating access like it’s one thing. It’s not.    

There are three layers, and they behave very differently:    

• Connectivity is whether you can reach the system at all.
• Authentication is whether it’s really you.
• Authorization is where you are allowed to go, what you can do once you’re there and how long you can be there.

Connectivity and authentication have become increasingly commoditized. Most organizations can point to mature tooling, common best practices and a set of controls that are at least defensible.    

‍Authorization is the layer that’s still complicated because it sits right at the intersection of security, engineering, operations and urgency. It’s messy because it changes depending on the environment. It’s messy because the “right” privilege depends on context, not just job title. It’s messy because production doesn’t care about your org chart or whether the authorization is for a human, agent or service.    

That’s the part most of the modern incidents and audit findings seem to circle, even when the headline is something else. And it’s also why a lot of security conversations feel like they’re stuck. We keep returning to login improvements and network gates because they’re familiar and tangible. We can buy them. We can measure them. We can deploy them and check the box.    

But the question that keeps showing up in the moments that matter is different: When someone (or an agent or a service) needs access to production, can you grant it with tight scope, enforce boundaries while it’s active and revoke it reliably when the reason for that access is gone?    

Or do you depend on standing privilege and static credentials, because it’s the only thing that works under pressure?    

This is not a moral failure. It’s a systems problem.    

Most stacks were built in an era when “being inside the network” implied trust and “being authenticated” implied legitimacy. That assumption doesn’t hold anymore, especially in production environments where the cost of a mistake is high and the number of actors keeps multiplying.    

So when people ask what “secure access” means, I try not to give a vendor answer. I try to give a realistic answer: secure access is not just knowing who logged in. It’s controlling what they could do, when they could do it and proving it later without reconstructing the story from scraps.    

If your access program can do that, you’re ahead of most!    

If it can’t, you’re not alone… but you’re also not going to solve it by bolting on yet another authentication feature and calling it progress. Reach out and let's figure out where you need help.