Privileged Access Management Architecture (Part 2): Discovery & Current-State Assessment

Introduction

In Part 1, I argued that a common reason PAM projects stall is that the team can't articulate what's already in place. This post is about fixing that. Before you build a reference architecture, shortlist vendors, or commit to a phasing plan, you need a defensible picture of the current environment: which privileged accounts exist, who and what uses them, where the credentials live, and what breaks if you start managing them.

Two things called "discovery" get conflated, so let's separate them up front:

• Discovery as a project phase. A bounded, mostly one-time effort to document the current state so you can scope, sequence, and design the solution. That's this post.
• Privileged Account Discovery as a capability. The ongoing, productised function — listed in the Part 1 capability model — that continuously finds new privileged accounts and credentials after the platform is live. That's a requirement you'll write, and a feature you'll evaluate, later in the series.

They're related: your project-phase discovery is a manual dry run of the capability you'll eventually automate. The gaps and surprises you hit by hand are exactly the things continuous discovery has to catch in production.

Why discovery is the phase that sinks projects

PAM is unusual among IAM disciplines because it acts on credentials that already exist and are already in use, often by systems nobody fully owns. An IGA rollout can start with a clean joiner-mover-leaver process and backfill the estate over time. A PAM rollout that rotates a service account password without knowing the four applications that depend on it causes an outage on day one. The cost of incomplete discovery isn't a missed requirement — it's a sev-1.

So the goal of this phase is not a tidy spreadsheet for its own sake. It's to answer three questions with enough confidence to design and phase the rollout:

1. What privileged access exists, and where? The inventory.
2. How is it used today, and by whom? The access patterns.
3. What depends on it, and what breaks if we change it? The blast radius.

Everything below serves those three questions.

What a PAM project needs to know about the current environment

1. Identity stores and directories

Start where the identities live, because everything else hangs off this.

• On-prem directory. Active Directory is still the centre of gravity in most enterprises. Capture forests, domains, trusts, and the privileged groups: Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, and any custom delegated-admin groups.
• Cloud directory. Entra ID, Okta, Ping, or equivalent. Capture privileged directory roles, the relationship to on-prem (hybrid join, sync scope, password hash sync vs pass-through vs federation), and any existing time-bound role features already in use.
• Standalone and legacy directories. LDAP, NIS, local /etc/passwd and /etc/shadow, mainframe RACF/ACF2/Top Secret, appliance-local user stores. These are where privileged accounts hide because they sit outside the directory everyone watches.

2. Privileged human accounts

The accounts people log in with. Categorise rather than just count:

• Built-in and local administrators. Local Administrator on Windows, root on Linux/Unix, sa on SQL Server, sys/system on Oracle, admin/enable on network kit. The classic targets, frequently shared, frequently with identical passwords across hosts (the LAPS-or-not question).
• Domain and directory-privileged accounts. Whether admins use dedicated privileged accounts or just elevate their daily-driver account is one of the most consequential things you'll learn.
• Shared and generic accounts. Team mailboxes for credentials, a shared firefighter login, the on-call account three people know the password to. These break individual accountability and are a primary justification for session brokering and recording.
• Break-glass and emergency accounts. How many, where stored, how monitored, and — critically — whether your future PAM platform is itself a single point of failure that the break-glass path must bypass.

3. Service and non-human accounts

This is where discovery gets hard and where the count is almost always wrong on the first pass.

• Windows service accounts and scheduled tasks. Accounts running services and tasks, including the ones with passwords set to never expire that nobody has touched since 2014. Note Group Managed Service Accounts (gMSA), which already solve part of the problem and shouldn't be migrated into a vault without thought.
• Application and app-to-app accounts. Service-to-service credentials, often hardcoded. The hardest to discover because they're invoked by code, not by people, and don't show up in directory query results as "privileged".
• Database accounts. Application connection accounts, DBA accounts, replication and backup accounts, linked-server credentials.
• SaaS and cloud service principals. Entra ID app registrations and service principals, AWS IAM users with long-lived access keys, GCP service accounts. These multiply faster than anyone tracks and overlap with the CIEM problem.
• Machine and workload identity (NHI). Increasingly the largest population by far. Treat non-human identity as a first-class discovery target, not a footnote.

4. Secrets sprawl

Privileged access isn't only interactive logins. A lot of it is secrets sitting in plaintext somewhere they shouldn't be.

• Hardcoded credentials in source code, config files, scripts, and infrastructure-as-code.
• SSH keys — frequently unmanaged, unrotated, and granting passwordless root across whole fleets. Key inventory is its own sub-project.
• API keys, tokens, and connection strings scattered across application config and CI/CD variables.
• Certificates and their private keys — adjacent to PAM and increasingly converging with it. At minimum, know where machine identity is owned.
• CI/CD secrets in pipeline variables, container images, and orchestration manifests.

5. The target estate

What you'll actually point the platform at. Coverage here drives connector requirements, licensing models, and which vendors can even play.

• Operating systems. Windows, the Linux/Unix distributions in play (and their versions), and anything legacy — mainframe, AS/400, Solaris, AIX, HP-UX — that narrows the vendor field considerably.
• Databases. Engines and versions, on-prem and managed (RDS, Azure SQL, Cloud SQL).
• Network, security, and OT devices. Routers, switches, firewalls, load balancers, and operational-technology kit, which often can't take an agent and needs proxy-based session brokering.
• Hypervisors and virtualisation. vCenter, Hyper-V, Nutanix — high-value targets in their own right.
• Cloud platforms. AWS, Azure, GCP — accounts/subscriptions/projects, the IAM model, and the entitlement explosion. This is where PAM and CIEM meet: the large majority of granted cloud permissions are never actually used, so right-sizing is a discovery output, not just a runtime feature.
• SaaS administration. Admin consoles for the platforms that run the business — your IdP, M365/Google Workspace, the CRM, the financial system.

6. Access patterns and workflows

The inventory tells you what. This tells you how — and it's what determines whether your design helps people or gets routed around.

• How privileged access is requested, approved, and provisioned. Walk the whole lifecycle, not just the grant. Request: is there a defined channel (a ticket, an IGA access request, a Slack message to a team lead) or do people just get added to a group on day one? Approval: who signs off, is it role-based or rubber-stamped, is there any separation of duties between requester and approver, and is the approval recorded? Provisioning: is the grant applied manually, by a script, or by an automated workflow — and how long does it take? Deprovisioning: this is where most environments fail. Time-bound grants that never expire, leavers whose admin rights outlive them, and project access that becomes permanent are the norm. Map this lifecycle for each major population, because your future PAM workflows (checkout, dual control, time-boxing, automatic revocation) have to either replace it or interoperate with it — and the manual steps you document here are the ones you'll be measured on automating.
• Standing vs just-in-time. The ratio of permanent privilege to on-demand elevation is your single best measure of current posture and the clearest before/after metric for the business case.
• Remote and third-party access — assess it as a capability, not just a pattern. PAM doesn't only secure remote privileged access; it can grant it, which means a privileged remote access (RPAM) capability can replace what's there today rather than sit alongside it. So inventory the current mechanisms: VPN-based admin paths, RDP/SSH gateways and jump hosts, vendor-specific support portals, and the ad-hoc tools that creep in (TeamViewer, AnyDesk, screen-share). Capture who relies on each — employees, contractors, third-party vendors, OT/ICS technicians — and how they authenticate. The point is that RPAM (often delivered as a browser-based, VPNless, ZTNA-style broker) is frequently the easiest slice to justify first, because it retires inbound firewall rules and VPN attack surface and produces audit-ready session evidence in one move. Treat current remote access as a capability you may migrate wholesale, and you change both the scope and the business case.
• Privileged workstation hygiene. Whether admins work from dedicated privileged access workstations or from the same laptop they read email on. This bounds how much your PAM controls actually protect.

7. Existing tooling and the overlaps

Run your current tooling against the basic capabilities list from Part 1 and mark coverage as full, partial, or none. The recurring patterns:

• A password manager treated as a vault. Useful for human credential storage; not a PAM solution — no session brokering, discovery, recording, or rotation against targets. Examples of the trap: enterprise password managers positioned as "we already have PAM".
• An IdP's privileged-role feature treated as PAM. Time-bound role assignment for the vendor's own cloud platform covers one slice of JIT but rarely vaults credentials, brokers sessions, or reaches Windows/Linux/database/network/OT targets.
• Bespoke scripts and a shared spreadsheet. Still the de facto service-account "solution" in many shops. The discovery, rotation, and audit gaps are the easiest part of the business case to write.

Document each tool against each L2 capability. The gaps you find here are the raw material for the functional requirements you'll define when you structure the project in Part 3.

8. Ownership, governance, and compliance drivers

• Ownership. Who owns each account and each target? Ownership ambiguity is the number-one cause of rotation outages, because nobody can confirm what depends on a credential before you change it.
• Existing policy. Password standards, access-review cadence, separation-of-duties rules — what's written down versus what's enforced.
• Regulatory and audit drivers. Whatever applies to you — SOX, PCI-DSS, HIPAA, NIS2, DORA, and the relevant control frameworks. These don't just justify the project; specific control requirements (session recording, credential rotation intervals, access certification) become functional requirements and influence phasing.

9. Dependencies and blast radius

The output that earns its keep. For every credential you intend to bring under management — especially service accounts — establish:

• What consumes it (applications, services, scheduled tasks, downstream integrations).
• What happens on rotation (graceful re-read, restart required, or hard failure).
• Who can confirm the above, and how you'll test it in a non-production path first.

This is the difference between a controlled rollout and an incident. Treat any credential you can't map as high-risk and onboard it in monitor-only mode before you rotate or broker it.

10. Initiatives already in flight

PAM never lands in a static environment. Part of discovery is mapping the other projects already running, because they create dependencies, contention for the same resources, and — most importantly — sequencing decisions. Some you must follow, some you can ride, and some you'll collide with if you don't coordinate. The usual suspects:

• Active Directory hardening. If an AD security or privileged-access hardening programme is already under way, your PAM design has to align with it rather than cut across it. Sequence behind that work, or co-design with it.
• Cloud migration. Targets that are mid-migration are moving goalposts. Onboarding a server estate that's about to be re-platformed to the cloud wastes effort; you may want to follow the migration rather than lead it.
• IGA / joiner-mover-leaver programmes. PAM and IGA overlap on access requests, approvals, and certification. Decide early which system owns the request workflow so you build complementary capabilities, not duplicate ones.
• Zero Trust / ZTNA and VPN retirement. Directly intersects the remote-access capability above. If the network team is already retiring the VPN, RPAM may be the privileged half of that same programme — sequence them together and you share the business case.
• MFA rollout or IdP migration. Your PAM platform will authenticate against the IdP and step up with MFA. If the IdP is changing underneath you, that's a hard dependency to time around.

For each in-flight initiative, record the dependency direction (does PAM depend on it, does it depend on PAM, or are they merely adjacent?), the owning team, and the timeline. That map is what lets you sequence sensibly instead of discovering a collision at go-live.

How to actually run discovery

No single method finds everything; you layer them.

• Directory and configuration queries. Enumerate privileged groups, local administrators, service-account flags, and SPNs from AD/Entra ID and host configuration. Cheap, fast, and a strong first pass — but blind to anything outside the directory.
• Console-led enumeration by the people who already have access. You almost certainly don't (and shouldn't) hold standing admin rights to every system in scope, and getting yourself provisioned everywhere is slow. The faster route is to task your business analysts, or the platform owners themselves, with signing in to each privileged console and exporting what's there. Have a BA log in to the Entra ID admin centre and pull the privileged role assignments — Global Administrator, Privileged Role Administrator, Application Administrator, and the rest — and do the same across AWS IAM, GCP IAM, vCenter, the database engines, and the network management platforms. It's quick, it produces an authoritative list per system, and as a side effect it tells you exactly who can already see this data today.
• Vendor discovery tools. Most PAM platforms ship a discovery engine, and several are free and standalone, which makes them useful even before you've chosen a product. Examples: CyberArk Discovery & Audit (DNA) — a free, agentless scanner for Windows and Unix estates that surfaces privileged accounts, local admins, SSH key trust maps, hardcoded credentials, and pass-the-hash exposure; BeyondTrust Privileged Access Discovery Application — free, unlimited network scans for privileged accounts and credentials and their risk state, complementing Password Safe's Smart Rules-driven discovery; Delinea Secret Server Discovery — account and dependency discovery built into the vault; and One Identity Safeguard, which has equivalent asset and account discovery. Run at least one of these. But heed the pitfall below: a vendor's scanner is tuned to what that vendor manages well, so corroborate with an independent pass.
• Automated discovery scans. Agentless (credentialed network scans against ranges) and agent-based (deeper local visibility, including local accounts and dependencies). For Active Directory specifically, independent and open-source tooling — BloodHound, PingCastle, Purple Knight — maps privileged groups, nested membership, and attack paths in a way that's vendor-neutral and keeps your PAM scan honest.
• Secrets scanning. Code, repositories, pipelines, and config for hardcoded credentials and keys. Different tooling from account discovery; budget for it separately.
• Cloud entitlement analysis. CIEM-style enumeration of human and machine principals and their effective permissions across AWS/Azure/GCP. Note the moving target here: Microsoft retired the standalone Entra Permissions Management product (end of sale April 2025, support ending later that year) and folded CIEM into Microsoft Defender for Cloud (Defender CSPM), so check what your tenant actually has. Entra PIM Discovery and insights (formerly the Security Wizard) is the quickest way to surface permanent Entra role assignments, and AWS IAM Access Analyzer does similar work on the AWS side.
• Interviews and workshops. The irreplaceable part. Platform, application, DBA, network, and cloud teams know about accounts no scan will surface — the integration that only one engineer understands, the appliance with a hardcoded admin password in the runbook. Scans find accounts; people explain them.
• CMDB and asset reconciliation. Cross-reference discovered targets against the CMDB. The deltas are informative in both directions: assets with no owner, and owners with no assets.

Common pitfalls

• Counting accounts instead of characterising them. "We have 12,000 privileged accounts" is not actionable. "We have 800 service accounts, 60% unowned, concentrated in three application estates" is.
• Trusting a single vendor's discovery tool. Useful, but it will be tuned to what that platform manages well. Corroborate.
• Treating non-human identity as an afterthought. It's usually the largest and fastest-growing population and the hardest to map.
• Skipping dependency mapping to save time. This is the time you don't get to save. It comes back as an outage.
• Letting discovery run forever. The opposite failure. Time-box it, accept that the inventory is a living artefact, and move into design with explicit known-unknowns rather than chasing completeness.

What discovery feeds

A good current-state assessment is the input to almost everything that follows:

• Structuring the PAM project (Part 3). Scope, phasing, sequencing, and the functional requirements all key off discovery. The dependency map and the in-flight initiatives drive sequencing — which populations and targets go in waves one, two, and three, typically highest-risk-and-best-understood first. The gaps between your capability model and your current state are what the requirements have to close. Discovery is what stops Part 3 from being a generic vendor wishlist.
• Reference architecture (Part 4). Connector coverage, deployment topology, high-availability and break-glass design, and where the platform sits relative to the network and directory boundaries you mapped.
• Vendor selection (Part 5). Your estate's OS, database, network, OT, and cloud mix is a hard filter on the shortlist before any demo.
• Licensing and commercials. This is where an inaccurate inventory hurts most directly. PAM is almost always licensed on one of two models — per privileged user or per managed asset/account — so your discovery counts effectively are your price. Undercount and you under-buy, then pay for it in change orders and mid-rollout true-ups when the real numbers surface; overcount and you over-commit on a multi-year contract. Knowing whether a vendor charges per user or per asset also tells you which discovery number to get most right: a user-based model makes your privileged-headcount accuracy critical, while an asset-based model puts the weight on your service-account and target counts — exactly the populations that are hardest to discover.
• The business case. The standing-vs-JIT ratio, the unowned-account count, and the secrets-sprawl estimate are the numbers that move executives.

Wrapping up

Discovery isn't glamorous and it rarely fits the timebox someone optimistically put on it. But it's the phase that decides whether the rest of the programme is engineering or firefighting. Get a defensible inventory, characterise it rather than just counting it, map the dependencies for anything you intend to touch, and write down your known-unknowns honestly.

In Part 3, Structuring the PAM Project, we take this current-state picture and turn it into a structured delivery — scope, phasing, workstreams, and the functional requirements the gaps you've found demand.

References