Zero Trust Network Access Won’t Save You If Standing Privileges Are Still Open

Most zero trust rollouts start in the same place: network segmentation, device posture checks, a shiny new ZTNA gateway replacing the old VPN. That’s genuinely useful work. But six months in, a lot of security teams end up in an odd spot: the network layer is locked down tight, and a breach still spreads the moment an attacker lands on one compromised laptop. Standing admin rights, shared service accounts, privileged sessions that never expire — none of that gets touched by a ZTNA rollout.

Zero trust network access controls where a connection is allowed to go. It doesn’t control what that identity is allowed to do once it’s there. Skip the identity and privilege side, and you’ve built a very modern-looking perimeter around the same old problem.

What zero trust network access actually covers — and where it stops

Zero trust network access replaces the old assumption that anything inside the corporate network is safe with a simpler rule: verify every connection, every time, regardless of location. Instead of a flat network where a user who’s authenticated once can roam freely, ZTNA creates narrow, application-specific tunnels. A contractor accessing a finance dashboard gets a path to that dashboard and nothing else, not the file server three subnets over, not the HR system, not the domain controller.

NIST’s Special Publication 800-207 lays out the model well: trust is never implicit, it’s evaluated continuously, and access decisions get made per-session based on identity, device state, and context. But NIST’s own guidance treats identity as the foundation of zero trust, not something bolted on after the network layer is done. A lot of ZTNA deployments quietly skip that part.

We see this play out the same way with a lot of clients: the network tunnel is scoped correctly, but the account using it still has standing privileged access to everything inside the application it connects to. The perimeter got smaller. The blast radius once you’re inside it didn’t.

The part doing the actual work: zero trust identity management

If ZTNA is the doorway, zero trust identity management decides who gets a key and how long that key stays valid. It’s where most of the real risk reduction happens, and it’s the harder, less glamorous half of the project.

In practice, that means every access decision, not just the initial login, factors in identity signals: is this the device the user normally uses, is the request coming from an expected location, has the account’s behavior changed in the last hour. Compare that to static role-based access, where someone gets “manager” permissions on day one and keeps them for three years regardless of what the job actually requires that week. That’s the exact kind of implicit, long-lived trust zero trust is supposed to eliminate.

We wrote more about the mechanics of continuous identity verification in our piece on identity and access management fundamentals, which is worth a read if the IAM side of this feels like the piece your team has under-invested in relative to the network controls.

What is standing privileged access, and why your ZTNA project probably didn’t touch it

Standing privileged access is any elevated permission — admin rights, root access, a service account with broad database read/write — that exists indefinitely, whether or not anyone is actively using it. Most organizations have far more of it than they realize. The 2025 Verizon Data Breach Investigations Report found credential abuse remains one of the most common entry points in confirmed breaches, and standing privileged accounts are consistently what attackers go looking for first, since they unlock the most once compromised.

It doesn’t take an external attacker exploiting the account for this to be a problem. It’s also why an ordinary phishing click on a help desk laptop turns into a domain-wide incident instead of a contained one. The account didn’t need admin rights at 2 p.m. on a Tuesday. It just had them, permanently, because provisioning it that way was easier than revisiting it later.

That’s the gap between “we deployed zero trust network access” and being zero trust in practice. The network says no to unauthorized paths. Standing privilege says yes to almost everything, all the time, to accounts that rarely need it.

Just in time provisioning: closing the gap without slowing teams down

Just in time provisioning flips the standing-access model around. Instead of holding permissions all the time, users request elevated access when they need it, for a specific task, for a bounded window. A database admin running a migration gets root for the 40 minutes the migration takes, not for the rest of their tenure. When the window closes, the access disappears automatically — no ticket to remember, no quarterly review to catch it three months later.

Done well, JIT provisioning replaces manual approval chains with policy-based automation: request, verify context, grant, expire. Done poorly, it just becomes another approval queue people find ways around. The difference comes down to how the workflow is built and whether it’s actually integrated with your identity provider rather than bolted on separately.

A few things separate JIT provisioning that works from JIT provisioning people route around:

• Time-bound by default, not by exception. Access expires automatically unless someone actively extends it — not the other way around.
• Scoped to the task, not the role. A migration needs database access for an hour, not the full admin console indefinitely.
• Integrated with the identity provider. If requests happen outside your IdP, you lose the audit trail and the automation both depend on.
• Approval logic based on context, not just a rubber stamp. Device posture, location, and recent account activity should factor into whether a request gets auto-approved or flagged for review.

This is where zero trust network access and identity governance start reinforcing each other instead of running as two disconnected projects. The network layer scopes where the connection can go. JIT provisioning scopes how long and how much that identity can do once it’s there. Together, they close the loop ZTNA alone leaves open.

Privileged user authentication needs a higher bar

One piece that consistently gets underweighted: privileged user authentication is often held to the same standard as everyday employee login. Multi-factor authentication for a marketing coordinator checking email is table stakes. For an account that can touch production infrastructure or customer data at scale, that same baseline MFA usually isn’t enough on its own.

Stronger controls here look like:

• Phishing-resistant authentication — hardware keys or platform passkeys instead of SMS codes or push notifications, which remain vulnerable to prompt bombing and SIM-swap attacks.
• Session recording for privileged activity, so there’s an actual record of what an elevated account did during its access window, not just that it logged in.
• Re-authentication tied to action sensitivity, not just login. A user viewing a dashboard and a user about to delete a production database shouldn’t face the same authentication bar.
• Separate credentials for privileged tasks, so an everyday account compromise doesn’t automatically hand over admin capability too.

CISA’s guidance on phishing-resistant MFA is a good baseline reference if this is an area your organization hasn’t formally revisited recently — a lot of “MFA-enabled” environments are still leaning on the weakest available factor.

None of this works in isolation

Network segmentation, identity-driven access decisions, eliminating standing privilege, hardened privileged authentication — none of these four does the whole job alone. Zero trust network access without identity management is a locked door with the key left in it. Identity management without addressing standing privilege still leaves attackers a wide target once they’re authenticated. And it all matters less if the accounts with the most access are protected with the least amount of friction.

The organizations that get the most out of a zero trust initiative treat it as one connected architecture rather than a checklist of separate purchases. That’s also the harder version to execute, which is why so many deployments stall at the network layer and never quite reach the identity and privilege work that makes the rest of it stick.

If your team has ZTNA in place but hasn’t looked closely at how standing privilege and JIT provisioning fit into that picture, that’s usually the highest-leverage next step: not another network control, but closing the identity gap sitting behind it.

Sennovate helps organizations design and manage identity security programs that connect zero trust network access with privileged access management and identity governance. If you want a second set of eyes on where your current setup has gaps, reach out to our team.