Anupam Nandan, CISSP, shares his experience of contending with poorly managed access management and the cybersecurity challenges created by persistent privileged access being granted at will.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
A few years ago, I led a privileged access management (PAM) transformation program for a large organization, managing tens of thousands of servers and over 10,000 users. The organization had grown rapidly, but its access model hadn’t evolved. Persistent privileged access was granted across environments – Windows, Linux and Unix systems, domain accounts as well as service accounts. These always-on privileges posed escalating risks: audit flags, lateral movement concerns and poor visibility into who accessed what, when and why.
With the rise of cloud-native operations, the organization’s security leadership knew it was time to act. Our mission was clear: implement a just-in-time (JIT) access model at scale and eliminate standing privileges across the enterprise. But turning that vision into reality presented several unexpected hurdles.
Owing to the very understandable problem we faced and the clear mission we were given, also to protect the confidentiality of the organization concerned, I’m not going to go into too much prior detail about this program. Instead, I’d like to describe as many important aspects of the program’s execution as I can, in the form of ‘lessons from the trenches’, in the hope it will help others to avoid certain steps that didn’t initially work for us and to focus, instead, on those that did.
Lessons From the Trenches, Part 1: What Didn’t Work (At Least At First)
In a program of this scale, it is improbable that everything worked as planned or expected first time. Indeed, not everything did – at least, not at first. This is what we didn’t get right the first time or didn’t work, and how we overcame it.
Use of Ephemeral Local Accounts for All Users
An ephemeral local account is a temporary user account created on a system that exists only for a limited time or specific purpose. The account is "ephemeral" because it isn’t persistent but, instead, is deleted or expires automatically once its intended use is complete. Our initial plan was to use such ephemeral local accounts to deliver JIT access across 30,000+ servers.
It sounded secure in theory but, in practice, didn’t align with how enterprise users worked: teams relied on domain accounts to run scripts, manage services and move files. We quickly realized we only needed to enable JIT for domain accounts to support real workflows.
An Automation Attempt
We assumed that application teams would manually add their servers to JIT policies. Again, the real world proved to be different: teams lacked the time and resources, and manual provisioning led to rollout delays. Our solution this time was a pivot to full automation, dynamically mapping systems to JIT policies using asset metadata.
Assumptions About Configuration Management Database (CMDB) Integrity
Automating anything successfully is predicated on the system inputs being correct. In this case, our automation logic relied on an accurate configuration management database (CMDB). However, we discovered that the CMDB lacked clear ownership-mapping and up-to-date system relationships, making early attempts at automation difficult or unreliable. With the benefit of hindsight, we should certainly have prioritized CMDB cleanup before automation.
Underestimation of Required User Education
We also underestimated the degree of user education that was required for the transformation. JIT was unfamiliar to most admins and a lack of training caused early resistance. When the rollout stalled, we built and added a change management stream: developing FAQs, short videos, help guides and running weekly office sessions. Adoption quickly improved.
Lessons From the Trenches, Part 2: Success Factors
Ultimately, our project was very successful. These are what I believe were the key success factors.
Close Collaboration with the PAM Vendor
The JIT functionality of our chosen PAM solution had JIT functionality in the early stages of development. We therefore worked closely with the vendor’s product team, sharing our enterprise use cases and influencing roadmap priorities. This partnership ensured product maturity kept pace with our rollout.
Alignment of Product and Program Timelines
Weekly joint planning sessions with both the vendor and internal stakeholders helped us track dependencies, prioritize feature gaps and avoid misalignment. The cross-team transparency that these joint sessions facilitated was critical to maintaining program momentum.
Joint Architecture Design
We organized cross-functional architecture workshops to bridge the gap between legacy access models and the future-state JIT framework. These design sessions were vital for building consensus and providing clarity across the infrastructure, identity and compliance teams.
Privileged Account Discovery
The deployment of automated discovery tools enabled us to detect and inventory privileged users and Active Directory groups. This provided us with real-time visibility into access sprawl, ultimately helping us to identify standing privileges that could be (and were) replaced with JIT policies.
Automation Across the Board
Automation played a critical role in accelerating our JIT rollout while reducing operational overhead. We built intelligent workflows to dynamically create JIT access policies based on user roles, server tags and group memberships, eliminating manual policy management. New servers were automatically onboarded into the appropriate policies upon provisioning, ensuring immediate coverage. Access requests were streamlined through integration with the ITSM system, enabling contextual validation and time-bound approvals without human intervention. We also automated communications, delivering policy updates, onboarding guidance and rollout announcements to end users and stakeholders. This end-to-end automation ensured speed, consistency and broad adoption across the enterprise.
Conclusions
JIT access isn’t just a control, it’s a mindset shift. When implemented thoughtfully, it transforms PAM from a reactive tool into a proactive enabler of zero trust. But the objective of this transition to JIT access wasn’t just about reducing risk, but about changing how access is granted and governed across the organization. Consequently, it demanded not only technical change but also process reengineering, stakeholder buy-in and cultural transformation. This ensured that the scale and scope of the program was significant.
For other security professionals embarking on a similarly significant journey, here are my top four takeaways from the experience of this program:
- Don’t Try to Boil the Ocean: It’s worth starting small and iterating
- Invest in Automation Early: As we found out, manual onboarding really doesn’t scale
- Get Your Data Right: A clean CMDB may make your automation. A ‘dirty’ database will break it
- Take Your Users With You: I know that this is an obvious one, but it is true that adoption rises when people understand the “why”
Anupam Nandan, CISSP, has over 16 years of cybersecurity consulting experience across financial services, healthcare, hospitality, government and technology sectors. He has held technical and leadership roles, with responsibility for delivering large-scale PAM and IAM programs, zero trust strategy and cloud/on-premise integrations. His cybersecurity work spans just-in-time access, machine identity governance and adaptive access automation for Fortune 500 enterprises.
