Auditing Entra ID Accounts and Privileges Without PowerShell Dependencies

Identity is where most real-world breaches actually start, and it is also where drift is easiest to miss. An account that should have been disabled during offboarding, or a role assignment that got left over from a project three months ago, does not show up in a dashboard unless you go looking for it. This is what that audit looks like in practice.

The core problem: drift, not a single bad config

Entra ID (formerly Azure AD) rarely fails because of one glaring misconfiguration. It fails because state drifts: an employee leaves, IT disables their laptop access, and the identity itself stays active for weeks because offboarding is a checklist item across three different systems and nobody owns reconciling all three. The audit exists to catch that gap between “the ticket says this account should be gone” and “the directory says it still exists.”

Cross-referencing accounts against tickets

The lifecycle audit pulls the full list of Entra ID user and service accounts and cross-references it against onboarding and offboarding ticket records. Any account marked complete on an offboarding ticket that is still enabled in the directory gets flagged. The same check runs in reverse for onboarding: accounts that exist in the directory with no matching onboarding record are worth a second look, since that is often how stale service accounts or one-off contractor access get created and forgotten.

Verifying privilege boundaries without restricted cmdlets

A constraint that shaped this work: some of the PowerShell cmdlets typically used for Entra ID role auditing were not available in the environment, either due to licensing tier or admin-restricted execution policy. That ruled out the usual Get-MgRoleManagementDirectoryRoleAssignment-style scripted approach as the primary method.

Instead, the audit verifies privilege boundaries for AI Administrator and Security Administrator roles directly through Microsoft Graph API calls and the Entra admin center’s role assignment views, cross-checked manually where the API access itself was scoped down. The AI Administrator role in particular is worth watching closely: it is a newer role with broad reach over AI-related resources and connectors, and it is easy for its assignment to expand further than intended if it is not audited on the same cadence as more established admin roles.

Compliance reporting and drift detection

The output is a standing report, not a one-time audit: stale accounts, unexpected role assignments, and policy violations get flagged on a recurring basis, not just when someone remembers to ask. That is the difference between an audit and a monitoring practice. A single point-in-time review tells you the state of things today. A recurring one tells you when things start moving in the wrong direction, which is the version that actually catches the drift before it becomes an incident.

The takeaway

Working around restricted cmdlets forced a more API-first approach than I would have defaulted to, and it turned out to be the more durable one: it does not depend on a specific module version or an admin-granted cmdlet that could be revoked later.