The conventional wisdom
You've likely heard the same advice: implement Privileged Access Management (PAM), centralize your identity stores, and you'll prevent breaches like SolarWinds. The logic seems sound. Forrester Research estimates that 80% of data breaches involve privileged credential abuse, so securing those credentials appears to be the solution.
Defense contractors and federal agencies are rushing to deploy PAM solutions, often viewing them as cure-alls. Your procurement office evaluates vendors. Your IT team handles implementation. Your compliance officer checks the box for NIST SP 800-171 requirement 3.5.1 (enforce minimum password complexity) and AC-6 from NIST SP 800-53 Rev 5 (employ the principle of least privilege). Everyone celebrates achieving "zero trust."
Why we disagree (or why it's incomplete)
PAM isn't the issue. The issue is assuming PAM solves identity sprawl when it's built on organizational chaos.
Here's what really happens: You centralize authentication into Active Directory or an Identity, Credential, and Access Management platform. You provision users once and automate privilege elevation. But the underlying mess of application-specific service accounts, legacy system local accounts, and Non-Person Entity credentials remains scattered across your infrastructure. You've centralized human login while leaving Non-Person Entity management distributed, undocumented, and vulnerable.
The DoD agency in the source material made "significant upgrades to its entire infrastructure" before PAM delivered value. That means they cataloged disparate identity repositories, mapped privilege requirements across systems, and redesigned workflows. The PAM deployment was step twelve, not step one.
Most organizations skip straight to step twelve because buying technology is easier than fixing processes. Your compliance framework doesn't help. DFARS 252.204-7012 requires you to implement NIST SP 800-171 controls for Controlled Unclassified Information, but it doesn't guide you on untangling years of credential accumulation before centralizing.
The evidence
Consider what the DoD agency faced before implementing Centrify. They had "dozens of disparate identity repositories as well as local account stores in many systems, and an entirely separate infrastructure for Linux servers." Every time an administrator needed privilege on a system, a new account, username, and password were created. This wasn't just a security gap; it was identity sprawl that made consistent security controls impossible.
The fix wasn't PAM. The fix was the groundwork before PAM: surveying the market, performing "extensive functional and security testing both in the lab and the infrastructure," and fundamentally redesigning access provisioning. Only after that groundwork did centralizing authentication into Active Directory and automating privilege management deliver "considerable cost savings" and simplified operations.
This aligns with what you see in Risk Management Framework implementations under NIST SP 800-37. The categorization and control selection steps (RMF steps 1 and 2) force you to inventory systems and data flows before selecting technical controls. Organizations that rush to Assessment and Authorization (steps 4 and 5) without completing that inventory work end up with authorization packages that don't reflect actual system boundaries.
When U.S. Cyber Command issued the communications tasking order that started this effort, they didn't just mandate PAM deployment. They "identified the issue, described the actions required to address it, gave a deadline for completion, and began the process of implementing a reporting structure to ensure compliance." That reporting structure exists because leadership knew teams would try to shortcut the hard organizational work.
What to do instead
Start with an identity audit that your compliance officer and infrastructure team conduct together. Map every system that processes, stores, or transmits CUI. For each system, document:
- All human accounts with elevated privileges
- All Non-Person Entity accounts (service accounts, API credentials, machine identities)
- The authentication method currently in use (password, PKI certificate, token)
- The privilege elevation method (sudo, RunAs, direct root access)
You're building the inventory that IA-2 (Identification and Authentication) and IA-4 (Identifier Management) from NIST SP 800-53 Rev 5 require but that most organizations document poorly. This inventory reveals where you actually have identity sprawl versus where you have documented, managed accounts.
Next, rationalize before you centralize. Eliminate duplicate accounts. Consolidate local account stores where technically feasible. For systems that must maintain separate identity repositories (legacy applications, air-gapped networks, specialized equipment), document why and establish manual reconciliation processes.
Only then should you evaluate PAM solutions. Your requirements should flow from the inventory and rationalization work. If you've documented 200 service accounts supporting automated processes, your PAM solution needs robust Non-Person Entity credential management. If you've identified privilege elevation happening through direct root access on 50 Linux servers, you need session management and keystroke logging for those specific systems.
When you implement, treat it as an infrastructure redesign, not a product deployment. The DoD agency's success came from replacing "multiple accounts, usernames, and passwords with a single account and a single authentication methodology." That's a fundamental change in how administrators work, not just new software.
When the conventional wisdom IS right
PAM absolutely belongs in your control implementation for AC-2 (Account Management) and AC-6 (Least Privilege). If you're pursuing Cybersecurity Maturity Model Certification Level 2 under 32 CFR Part 170, you'll implement these controls as part of your assessment scope.
The conventional wisdom is also right that you can't achieve zero trust without strong identity management. The principle of "never trust, always verify" requires knowing who's requesting access, the context of that request, and the risk of the access environment. PAM provides the technical enforcement mechanism for those decisions.
Where the conventional wisdom succeeds is in organizations that have already done the hard work of identity rationalization -- either because they're new enough to have started clean, or because they've suffered a breach that forced organizational change. For those teams, PAM delivers exactly what the vendors promise: centralized visibility, automated provisioning, and reduced credential sprawl.
But if you're still discovering service accounts during incident response, PAM won't save you. Fix the sprawl first, then centralize. Your auditor will thank you.
