If everything your developers do requires a power account, what exactly is the regular account for?

This isn’t a rhetorical question. It’s the daily reality for tens of thousands of engineers in banking. A 2025 CyberArk/CSO Online study found that 91% of IT professionals maintain always-on privileged access. The same study found that just 1% of organizations have implemented Just-in-Time (JIT) access for privileged accounts.

Ninety-one percent always on. One percent doing anything about it.

We have a $280 billion cybersecurity industry built on the principle of least privilege, and we can’t even get the basics right. The problem isn’t that JIT access is hard to implement—it’s that the dual-account model we’ve relied on for decades was never designed for what modern developers actually do.

When Your Regular Account Becomes Useless

Think about what a typical bank developer does on any given day:

• Push code to repositories (privileged—source code access)
• Trigger CI/CD pipelines (privileged—production deployment chains)
• Spin up containers and manage orchestration (privileged—infrastructure modification)
• Query databases for debugging (privileged—customer data access)
• SSH into servers for troubleshooting (privileged—direct system access)
• Review cloud infrastructure configurations (privileged—security-relevant settings)
• Read application logs (privileged—may contain PII)

Every single task on that list gets classified as “privileged” under most banking IAM policies. The result? Your regular account can check email and open a browser. Everything else requires the elevated account.

This creates a binary privilege model: useless or elevated. Nothing in between.

Jerome Saltzer formulated the Principle of Least Privilege in the 1970s: users should operate with “the minimum necessary to complete the job.” The key word is minimum. The principle assumes a spectrum of access levels, not a toggle switch.

The FFIEC authentication guidance defines a “privileged user” as someone who can perform security-relevant functions that ordinary users cannot. But when every function is classified as security-relevant, the distinction between ordinary and privileged evaporates entirely. If everyone is privileged, no one is—because there’s no baseline to measure privilege against.

The productivity impact is real. A 2024 Harness developer experience report found that 69% of developers lose 8+ hours per week to workflow inefficiencies. A 2025 Chainguard engineering reality report found that 88% say tool switching and context changes hurt their productivity. Dual-account friction is a major contributor to both statistics—the constant cycle of logging out, logging in with elevated credentials, re-authenticating, timing out, and starting over.

Friction Without Security

Here’s the real problem: dual accounts with always-on privileged access don’t actually improve security.

If a developer’s privileged account is active 40 hours a week—because it has to be—the attack surface is identical to having no separation at all. A compromised credential gives an attacker the same access window whether the account was “always-on privileged” or “single account with everything.”

Security theater is when a control exists to look like security without providing it. A control that 91% of its users universally bypass isn’t a control—it’s a liability. It consumes administrative overhead, training budgets, and developer patience without reducing actual risk.

The metric that matters is privilege time window: how many hours per week is elevated access active?

Current Dual-Account Model:
├── Regular account (email, browser)
│   └── Active: 40 hrs/week
├── Privileged account (everything else)
│   └── Active: 40 hrs/week
└── Effective privilege exposure: 40 hrs/week

JIT Access Model:
├── Standard account (all daily tools)
│   └── Active: 40 hrs/week
├── Elevated privileges (on-demand)
│   └── Active: ~2-4 hrs/week (as needed)
└── Effective privilege exposure: 2-4 hrs/week

The difference is staggering. BeyondTrust research shows JIT access reduces threat windows by over 90%. That’s not a marginal improvement—it’s a fundamentally different risk posture.

And there’s a risk nobody talks about: accidental damage. A developer running as admin 40 hours a week will eventually execute a destructive command in the wrong context. A typo in a privileged session against a production database isn’t a security breach—but the impact can be identical. JIT access limits the window for human error, not just malicious exploitation.

What JIT Actually Looks Like: Azure

Microsoft’s Azure ecosystem has the most mature native JIT tooling. Here’s what’s available today—not roadmapped, not in preview, shipping and production-ready.

Entra PIM (Privileged Identity Management) — The core of Azure JIT. Developers are assigned eligible roles rather than active roles. When they need elevated access, they activate the role through PIM with mandatory MFA, optional approval workflows, and a defined time window (1-24 hours). Every activation is logged with who, what, when, and why. When the window expires, access reverts automatically. No more “I forgot to log out of the admin account.”

Privileged Access Groups — Extends JIT beyond Azure roles to group-based access. This is critical for Azure DevOps integration: repository access, pipeline permissions, and project admin rights can all be granted through time-bound group membership. A developer activates membership when they need to approve a production pipeline, and it expires after the deployment is complete.

Conditional Access — Context-aware policy enforcement that evaluates device compliance, network location, sign-in risk level, and session context before granting access. Combined with Continuous Access Evaluation, policies are enforced in near real-time—not just at login. A developer accessing production from an unmanaged device on public WiFi gets a different access decision than one on a compliant device inside the corporate network.

JIT VM Access — Network-level JIT for virtual machine access. Default state: all inbound management ports are blocked via NSG rules. When a developer needs SSH or RDP access, they request it through JIT VM Access, which creates time-limited allow rules (default 3 hours). When the window closes, the NSG rules revert to deny-all. The VM’s attack surface literally doesn’t exist until someone needs it.

Managed Identities and Workload Identity Federation — Eliminates static credentials for CI/CD pipelines entirely. GitHub Actions and Azure DevOps pipelines authenticate using short-lived OIDC tokens instead of stored secrets. No passwords to rotate, no service account credentials to manage, no secrets in pipeline configurations. This is the non-human equivalent of JIT—workloads get credentials only when executing, and those credentials expire immediately.

Key Vault with Auto-Rotation — Centralized secret management with automatic credential rotation. Applications access secrets through managed identities (no human credentials involved), and Key Vault references allow App Service and Functions to resolve secrets at runtime without storing them in configuration.

There’s a critical gap worth noting: PIM doesn’t support service principals or managed identities—only human user accounts. If your JIT strategy depends on PIM for non-human identities, you’ll need a complementary solution. This is one area where the Azure native tooling falls short.

A zero-trust implementation in the financial sector combining PIM with Conditional Access reported a 68% reduction in high-severity security alerts. Not because fewer attacks happened—because the always-on attack surface that generated most alerts simply stopped existing.

What JIT Actually Looks Like: CyberArk

CyberArk has been in the privileged access business longer than most developers have been coding. Their approach is different from Azure’s—purpose-built for PAM rather than bolted onto an identity platform.

Privilege Cloud — CyberArk’s SaaS PAM platform handles credential vaulting, session recording, and credential brokering. The key differentiator: the developer never sees the password. They request access, Privilege Cloud authenticates on their behalf via session proxy, records the entire session, and revokes access when done. Terraform and Ansible integrations mean infrastructure-as-code workflows get the same treatment.

Secure Cloud Access — Zero Standing Privileges across AWS, Azure, and GCP. Developers request cloud console or CLI access through CyberArk, receive time-bound credentials, and lose access when the window closes. This solves a problem Azure PIM can’t: cross-cloud JIT access from a single control plane. For banks running multi-cloud (most of them), this is significant.

Conjur and Secrets Manager — Ephemeral secrets for DevOps pipelines. Conjur issues short-lived credentials to Jenkins, Kubernetes, Terraform, and other automation tools—credentials that auto-expire and are unique per session. A European bank deploying Conjur reported an 80% increase in DevSecOps adoption because developers stopped fighting the secrets management process.

Endpoint Privilege Manager (EPM) — Workstation-level JIT. Instead of giving developers permanent local admin rights, EPM provides just-in-time elevation for specific applications. A developer can install an approved package or run a debugging tool with elevated privileges without having standing admin access to their workstation. Ring-fenced application control means only approved executables can run elevated. IIFL Group in India deployed EPM to remove standing local admin across their developer fleet.

Identity Flows — Multi-step approval workflows for access requests. Self-service with configurable approval chains: a developer requests production database access, their manager approves, security reviews the justification, and access is granted for a defined window. The entire chain is auditable.

Azure Integration — CyberArk and Azure PIM are complementary, not competitive. EPM integrates with Entra ID for unified identity. CyberArk fills the gaps PIM doesn’t cover (service principals, cross-cloud, workstation elevation), while PIM handles native Azure role management. Palo Alto Networks’ 2025 acquisition of CyberArk’s QRadar assets underscores the industry convergence. CyberArk holds the Gartner Magic Quadrant Leader position for PAM—seven consecutive years.

Banking deployments include DZ BANK (Germany’s second-largest bank), BRAC Bank (Bangladesh—full deployment in 6 months), and DCB Bank (India).

Beyond the Big Two

Azure and CyberArk aren’t the only options. Several alternatives deserve attention depending on your environment.

BeyondTrust — Claims over 90% attack surface reduction through JIT privilege elevation. Strong integration with ServiceNow and PagerDuty for approval workflows tied to incident management. If your organization already uses ServiceNow for change management, BeyondTrust’s integration is notably seamless.

Teleport — Open-source, certificate-based access for SSH, Kubernetes, databases, and web applications. No long-lived credentials exist in the system—every session uses short-lived certificates. Multi-protocol support from a single platform makes it compelling for organizations that want JIT across infrastructure, not just cloud IAM. The open-source model also means you can audit the implementation.

HashiCorp Vault — Dynamic secrets with TTL-based leases. Instead of storing static database credentials, Vault generates unique credentials per client request with defined time-to-live. When the TTL expires, the credentials are automatically revoked. Every consumer gets unique credentials, which means compromising one set doesn’t compromise others—and forensics can identify exactly which client was compromised.

The Business Case Nobody’s Making

Security teams argue for JIT on risk reduction. But the business case is actually stronger on the productivity side, and almost nobody is making it.

A fully loaded developer in banking costs between $112-117 per hour when you account for salary, benefits, tooling, and overhead. If dual-account friction wastes just 15 minutes per day—logging in, switching accounts, re-authenticating after timeouts, re-establishing sessions—that’s $7,000 per developer per year. Scale that to 200 engineers and you’re looking at $1.4 million annually in lost productivity. From a control that doesn’t improve security.

McKinsey’s Developer Velocity Index found that top-quartile companies in developer experience see a 4-5x revenue growth advantage over bottom-quartile peers. Developer friction isn’t just a cost—it’s a competitive disadvantage.

The insurance angle is equally compelling. An estimated 75% of cyber insurers now require or incentivize JIT access controls in their underwriting criteria. Standing privileged access is becoming an actuarial liability.

And here’s what audit teams should care about: JIT produces richer audit trails than dual accounts. Every access request captures who requested it, what they needed, why they needed it, who approved it, when it started, and when it ended. Compare that to a dual-account model where the audit trail shows “admin account logged in at 8 AM, logged out at 5 PM.” Which one would you rather defend to an FFIEC examiner?

This is a specific instance of the broader compliance tax—a governance control that costs real money and real productivity without delivering proportional security value.

The Gaps Nobody Talks About

I’d be dishonest if I presented JIT as a simple swap. There are real challenges that vendor marketing glosses over.

Migration is organizational, not just technical. You can deploy PIM in a week. Getting 200 developers to change how they access systems takes months. Training, documentation, workflow redesign, exception handling—the human side is harder than the technical side.

Policy design is genuinely hard. What access is auto-approved? What requires manager approval? What requires security team approval? Get this wrong in either direction and you’ll either create a rubber-stamp approval process (security theater again) or grind development to a halt with approval bottlenecks.

Legacy systems don’t support JIT. That mainframe running COBOL? The 20-year-old Oracle database? The vendor appliance with hardcoded credentials? JIT works beautifully for cloud-native systems and poorly for the legacy infrastructure that banks are actually built on.

CyberArk licensing is significant. Enterprise PAM isn’t cheap. The per-user, per-endpoint pricing model can make finance teams flinch, especially when the comparison is “free” (the existing dual-account model that doesn’t actually cost zero, but appears to).

Cultural resistance comes from both sides. Security teams resist because JIT feels like “giving developers the keys.” Development teams resist because any new process feels like more friction—even when the net result is less. Getting both groups aligned requires executive sponsorship, not just a good technical argument.

Where This Leaves Us

The dual-account model was designed for a world where “privileged access” meant a small set of administrative functions performed occasionally by a small set of administrators. That world doesn’t exist anymore. When every developer action touches production systems, cloud infrastructure, customer data, and deployment pipelines, the entire workforce is privileged by default.

The fix isn’t to keep pretending dual accounts provide meaningful security. It’s to implement what Jerome Saltzer actually meant: access scoped to the minimum necessary, for the minimum duration, with full accountability.

JIT access isn’t a new idea. It’s the technical implementation of a 50-year-old security principle that we’ve been too organizationally inertia-bound to adopt. The tooling is mature. The business case is clear. The security improvement is measurable.

Stop thinking “control developers.” Start thinking “enable developers within boundaries.”

The privilege paradox has a solution. We’ve just been too comfortable with the status quo to deploy it.

---

If this resonated and you work in identity at a bank, the natural companion piece is Non-Human Identities: When AI Agents Need Employee Badges—where the identity challenge extends beyond human developers to AI agents that also need scoped, time-bound, auditable access.

Dealing with privileged access friction at your org? I’d love to hear how you’re handling it. Find me on X or LinkedIn.