Auditing privileged access for an organization that never formally managed it is a specific kind of engagement that's different from evaluating an existing PAM program. You're not reviewing whether controls are working — you're discovering what exists, assessing what it means, and then making recommendations for a state that doesn't currently exist. The scope is genuinely large, the surprises will be frequent, and the question of how deep to go is one of the most important decisions you'll make early in the project.

Here's how to approach both the audit and the modernization question.

Phase One: Discover What Actually Exists

Before you can audit privileged access, you need a complete and accurate picture of the identity landscape. In an organization that grew quickly with IT as an afterthought, this phase will take longer than expected and produce surprises.

AD and Active Directory Groups

Start with the Domain Controller. Pull a complete export of users, groups, and Organizational Units. The immediate priorities are the high-risk groups: Domain Admins, Schema Admins, Enterprise Admins, Backup Operators, and any other groups with elevated DC-level permissions. These are the accounts that represent the highest risk if they belong to people who shouldn't have that access, have left the organization, or have been compromised.

In environments that grew without governance, these groups accumulate members over time without meaningful review. You will likely find:

• Former employees or contractors whose domain accounts were never disabled
• Users who were added to privileged groups for a specific project or task and never removed
• Service accounts with domain admin membership that was granted for convenience rather than necessity
• Nested group memberships where a standard user group was added to a privileged group at some point and nobody noticed

Document everything before changing anything. The temptation to immediately start cleaning up discovered problems is understandable, but understanding the full scope before making changes prevents disrupting legitimate processes that depend on configurations that look wrong but aren't.

Office 365 and Licensing

The older O365 plans add a second layer of identity complexity. Check Exchange admin roles, SharePoint site collection administrators, Teams admin roles, and Global Administrator assignments. In organizations that assigned Global Admin broadly because it was the easiest way to give someone elevated access to one thing, you'll often find far more Global Admins than any organization needs or should have.

Also check external users and guests in the Microsoft 365 tenant — former partners, contractors, and vendors who were given guest access and never removed are a common finding.

Orphaned Accounts

Cross-reference your AD user list and your O365 user list against an authoritative source of current employment — payroll, HRMS, or HR records. Users who appear active in AD or O365 but don't have active employment records are orphaned accounts. In an organization that grew fast, this list can be substantial.

Orphaned accounts are the highest-priority remediation item because they represent active access with no legitimate owner. Former employees with domain admin access or Global Admin assignments are not theoretical risks — they're active access vectors.

Rogue Devices and Unmanaged Access

For the concern about rogue devices accessing the DC environment: inventory what's connecting to the network. Network scanning tools can identify devices that are communicating with domain controllers but aren't enrolled in any management system, aren't in the computer OU of AD, or are connecting from outside expected network ranges.

In environments without Intune or another MDM, device visibility is largely limited to what's in AD and what network traffic analysis can surface. This is one of the stronger arguments for moving to Intune as part of the modernization — you can't govern what you can't see, and device management is the foundation of a Zero Trust architecture.

Phase Two: Audit What You've Found

Once you have the complete inventory, the audit work is evaluating whether what you found is appropriate.

Privilege Level Relative to Current Function

For every user in a high-privileged AD group or O365 admin role, the question is whether their current job function requires that level of access. This requires talking to someone who knows what each person does — typically their manager or department head. The IT team often doesn't have this context for every user, which is why the review has to involve the business side.

The specific pattern to look for: users who were given elevated access for a reason that no longer applies (a project, a temporary responsibility, a role they held previously) and have retained it because nobody reviewed it after the original justification expired.

Activity as a Secondary Signal

For users where access level seems questionable, last login data provides additional context. A user with Domain Admin access who hasn't logged into any domain-joined system in three months is a different risk profile from one who logs in daily. Activity data doesn't replace the function-based review — someone can be actively logging in with access they no longer need — but it surfaces high-priority revocation candidates quickly.

Service Accounts and Non-Human Access

Service accounts deserve their own review track. They frequently have elevated permissions, they don't have associated human identities to evaluate function against, and they're often the most neglected part of the identity landscape in organizations without formal PAM.

For each service account, document: what system or application it's associated with, what permissions it holds, whether those permissions are actually required for the application to function, and whether the credentials are actively rotated. Service accounts with Domain Admin membership that exist to run a specific scheduled task are a common and unnecessary over-privilege pattern.

How Deep to Go on Network Evaluation

The "how deep do you go" question on network evaluation has a practical answer: go deep enough to answer the questions that AD and O365 inventory can't answer.

AD tells you what's in the directory. O365 tells you what Microsoft knows about. Network evaluation tells you what's connecting to those systems from outside those inventories — devices accessing domain resources that aren't domain-joined, external connections that don't go through expected authentication paths, and traffic patterns that suggest unauthorized access or compromised credentials.

For the scope of this engagement, the minimum is: identify devices connecting to domain controllers that aren't in the AD computer inventory, and identify authentication failures and successes from unexpected sources in the DC event logs. Beyond that, the depth depends on how concerning the initial findings are and what budget the client has for the evaluation.

Don't promise comprehensive network security assessment scope as part of an access review project unless it's explicitly in scope and priced accordingly — these are different engagements that can be done sequentially.

On Microsoft PIM: Is It Worth It?

Microsoft Privileged Identity Management is a meaningful component of the M365 security stack, and for an organization moving from a traditional DC setup to a modern Microsoft cloud architecture, including PIM in the target state is the right recommendation. Here's what the implementation actually involves and what to expect.

What PIM Does

PIM implements just-in-time privileged access for Entra ID roles. Instead of permanently assigning Global Admin or other privileged roles to users, PIM allows users to activate those roles when they need them, for a defined time window, with optional approval and MFA requirements. When the window expires, the role assignment deactivates automatically.

For an organization where privileged access has been persistent and unreviewed, this is a significant improvement. The blast radius of a compromised privileged account is limited because the account isn't persistently privileged — it has to actively request activation, which creates a logging event and an approval opportunity.

What PIM Doesn't Do

PIM governs Entra ID roles and Azure resource roles. It doesn't govern application-level permissions within O365 applications (Exchange admin, SharePoint site owner, Teams admin), it doesn't govern on-premises AD group membership, and it doesn't manage privileged access in non-Microsoft applications.

For the full-scope PAM requirement — password vaulting, session monitoring, privileged access for non-Microsoft systems — PIM is one component of a solution, not the complete solution. Organizations with significant non-Microsoft privileged access requirements (server infrastructure, network devices, database admin access) typically need a dedicated PAM tool (CyberArk, BeyondTrust, Delinea) alongside Microsoft PIM.

The Full M365 Stack: What to Recommend

The target state you've described — AAD SSO + Intune + Conditional Access + PIM — is the right architecture for a Microsoft-centric environment. The implementation typically goes in this sequence:

Entra ID SSO first. Get all users into Entra ID as the authoritative identity source, configure SSO for the applications in scope, and establish MFA as a baseline requirement. This is the foundation everything else builds on.

Intune and Conditional Access together. Enroll devices into Intune management and configure Conditional Access policies that enforce device compliance as a condition for accessing sensitive resources. This is what addresses the rogue device concern — compliant, Intune-managed devices are required for access to organizational resources.

PIM after the foundation is stable. PIM is easier to implement when the underlying role structure is clean. The privileged access audit you're doing now produces the clean role inventory that makes PIM configuration straightforward rather than a mess of inherited over-privilege.

Implementation Experience

PIM setup itself is not technically complex — it's configuration work in the Entra ID portal. The complexity is organizational: deciding which roles to put under PIM governance, who the approvers are for each role, what the maximum activation duration should be, and getting the affected privileged users comfortable with the changed workflow.

The friction point is the users who are currently permanent Global Admins and will be required to activate their privilege when they need it. This requires change management work alongside the technical implementation — explaining why the change improves security, making the activation workflow as low-friction as possible, and setting expectations about response times for approvals.

Organizations that have gone through this transition consistently report that the initial resistance to PIM is higher than the ongoing operational impact after a few weeks of use. The activation workflow becomes routine, and the security benefit — privileged access that's temporary, logged, and approval-gated — is demonstrable to the organization's leadership.

Making the Case for Investment

For the client conversation about whether this modernization is worth it: the risks you've described — unknown privileged access, potentially active accounts for former users, unmanaged devices accessing domain resources — are exactly the risks that made headline breaches happen. The "we grew fast and IT was an afterthought" environment is a known attack pattern.

The audit you're conducting will find things that make the business case for investment easier to make. Document what you find — the specific orphaned accounts, the over-privileged users, the unmanaged devices — and present them as the current risk posture. The cost of the modernization becomes easy to justify alongside a concrete inventory of what the current state actually looks like.