Every era has its “worked great” tech. Then the environment changes.

Every day, I talk with security teams who are trying to modernize privileged access. The intent is right. The problem is simpler: we are still treating authentication and network access as the strategy.

Like all great things, they had their moment. They got us through the last era of infrastructure. But the environments we are securing now have changed, and those first two layers cannot carry the weight on their own.    

If you step back, access has three layers:    

• Connectivity: can you reach the system
• Authentication: is it really you
• Authorization: what are you allowed to do once you’re there

Most conversations about “governing access” still start with the first two layers. What network can they connect to. Who can log in. Whether the right tunnels, network segments, gateways, SSO and MFA are in place.    

Historically, teams have secured access at the first couple of layers, using VPNs, firewalls and vaults. Over the years, as architectures have evolved from data centers to cloud, and now AI-native, the first couple of layers have seen tremendous progress and standardization.    

As a result, most SASE vendors have commoditized connectivity, and IdP vendors have commoditized authentication using SSO and MFA.    

‍It also means the center of gravity has shifted and disbursed. The exposures that keep showing up tend to be inside the walls, after someone is already connected and authenticated, in environments we deem as “safe” because they’re segmented or gated.    

If your access program stops with authentication, it’s a bit like making calls with that flip phone. You can still communicate. You can still find people. But you’re going to struggle the moment the pace of innovation picks up.    

Authn based access is the flip-phone equivalent of control planes. Strong authentication is now largely table stakes. Network connectivity, similarly. You can argue vendors and architectures forever, but for most organizations these are now standardized layers of the stack. The real question is what happens after someone gets in and proves who they are?    

Authorization. Specifically, I mean how do you manage the full lifecycle of authorization of every identity in your environment - whether it's an employee, contractor, workload or agent. The operational reality of authorization at runtime, when someone needs escalated privileges, that is time sensitive and needs to be secure, least-privileged and audible.    

Authorization is the layer where you need to answer accurately and consistently:    

• who can do what
• in which systems
• for how long
• under what conditions
• with what approvals
• with what evidence
• with what audit trail

That’s what auditors and incident reviews are asking you to reconstruct after the fact. In multi-cloud and hybrid environments, it can get very complicated. For most organizations, this is still an arduous process of piecing together logs, screenshots, emails, JIRA/Servicenow tickets and chat threads.     ‍

This is a big reason we built P0 Security.    

We continue to see organizations that have rightfully invested in SASE and IdP technology to elevate their approach to the first two layers of defense, then treat the granting and revoking of privilege as a messy, manual process that lives in exceptions. Until something goes wrong or an audit forces the issue. Business innovation has outpaced the controls that served us well when everything was still on the cloud and human administrators were the only “things” accessing sensitive systems. That’s no longer the reality for a vast majority of businesses.

By decoupling authZ from network and authN controls and tying it directly to your IdP, P0 eliminates shared accounts and standing access while streamlining engineering workflows. Instead of managing static credentials or bastions and proxies, P0 manages the authorization itself. Automating just-enough and Just-in-Time (JIT) privilege for all identities, including human users, non-human workloads and AI agents. Zero standing privilege by design.

So here’s a practical test:    

If a developer is on call and needs production access immediately to fix an issue, can your organization grant that access in minutes, scoped to the system they need - whether that's a database, virtual machine, cloud console of cluster -  and automatically deprovision when the work is done… without creating standing access, static credentials or overprivilege as a side effect? Can you easily reference your logs afterwards to see exactly who did what, when, why and with what approvals?    

If the honest answer is “not really,” then it’s worth reconsidering your approach to access.    

Because in 2026, if “governing privileged access” still means vaulting static credentials and shared jump-host accounts, you’re solving yesterday’s problem with yesterday’s tools.