Entra ID Audit: Eliminate Weak MFA and Standing Roles

Attackers use AI to automate phishing and social engineering, and an intercepted SMS code or push approval is enough to open the door to an account. If that account holds a standing administrator role, the exposure extends far beyond a single mailbox. This audit guide gives you a method, a read-only script and a decision grid to find weak MFA methods and standing privileges in Microsoft Entra ID, formerly Azure AD.

Why this audit comes before AI agents

On October 29, 2026, Microsoft published a message from Melanie Maynes on the Microsoft Entra blog. It reminds readers that the principles that protect users must extend to every agent identity. The accompanying guide, Secure identity to get ready for AI, sets out three workstreams in order: phishing-resistant MFA (multifactor authentication), removal of standing privileges with Microsoft Entra Privileged Identity Management (PIM), and a unified policy engine.

The logic of the order is simple: an AI agent inherits the hygiene of your tenant. If your administrators authenticate by SMS and keep Global Administrator permanently, adding agent identities only enlarges an already fragile surface. Auditing human accounts first is therefore a prerequisite, not an optional step.

Which MFA methods should be considered weak?

A method is weak as soon as an attacker can obtain or relay the second factor without possessing the victim's device. Microsoft's message explicitly cites SMS codes and push approvals as interceptable. The methods to aim for are device-bound passkeys, FIDO2 security keys, Windows Hello for Business, synced passkeys and certificate-based authentication.

Synced passkeys have been generally available in Microsoft Entra ID since the March 2026 announcement, according to the Microsoft Entra releases and announcements page. For administration accounts, Microsoft's recommendation remains device-bound passkeys or FIDO2 keys. Synced passkeys are better suited to deployment across the general population.

Why a standing role makes everything worse

A standing assignment exposes the role 24 hours a day, even when nobody is using it. A token stolen on a Sunday evening therefore carries the same rights as a token issued in the middle of an intervention. PIM replaces this model with eligible roles, activated for a limited time with justification and MFA.

Microsoft's guide recommends running PIM discovery, then converting static roles into time-limited activations. The page Discovery and insights (preview) for Microsoft Entra roles in PIM describes this wizard, which the documentation flags as being in preview. Guests, for their part, are governed by expiring access packages.

Implementation

The script below is read-only: it lists active Entra role assignments with no end date, then classifies the authentication methods of the accounts concerned. It writes nothing to the tenant, so no simulation mode is needed.

• Modules: Microsoft.Graph.Authentication, Microsoft.Graph.Identity.Governance and Microsoft.Graph.Identity.SignIns.
• Delegated permissions: RoleManagement.Read.Directory and UserAuthenticationMethod.Read.All. The account running the script must also hold an Entra role authorised to read other users' authentication methods; check the exact role in the Microsoft Graph documentation.
• Output: a CSV file audit-privileges.csv and a summary by verdict in the console.

1Install-Module Microsoft.Graph.Authentication, Microsoft.Graph.Identity.Governance, Microsoft.Graph.Identity.SignIns -Scope CurrentUser

1# Connexion avec les deux permissions minimales, en lecture seule
2Connect-MgGraph -Scopes 'RoleManagement.Read.Directory','UserAuthenticationMethod.Read.All' -NoWelcome
3 
4# Types de méthodes tels que renvoyés par Microsoft Graph
5$faibles = @('#microsoft.graph.phoneAuthenticationMethod','#microsoft.graph.emailAuthenticationMethod','#microsoft.graph.softwareOathAuthenticationMethod')
6$resistantes = @('#microsoft.graph.fido2AuthenticationMethod','#microsoft.graph.windowsHelloForBusinessAuthenticationMethod')
7 
8# Toutes les instances d'affectation, avec le principal et la définition du rôle
9$affectations = Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance -All -ExpandProperty 'principal,roleDefinition'
10 
11# Affectation permanente = active (Assigned) sans date de fin ; les activations PIM (Activated) sont exclues
12$permanentes = $affectations | Where-Object { $_.AssignmentType -eq 'Assigned' -and -not $_.EndDateTime }
13 
14$rapport = foreach ($a in $permanentes) {
15    $props = $a.Principal.AdditionalProperties
16    $nature = ($props['@odata.type'] -replace '#microsoft.graph.', '')
17    $methodes = ''
18    $verdict = 'Non évalué (principal non utilisateur)'
19 
20    if ($nature -eq 'user') {
21        try {
22            # Liste des méthodes enregistrées pour ce compte
23            $types = @(Get-MgUserAuthenticationMethod -UserId $a.PrincipalId | ForEach-Object { $_.AdditionalProperties['@odata.type'] })
24            $methodes = ($types | ForEach-Object { $_ -replace '#microsoft.graph.', '' }) -join ';'
25            $aResistante = @($types | Where-Object { $resistantes -contains $_ }).Count -gt 0
26            $aFaible = @($types | Where-Object { $faibles -contains $_ }).Count -gt 0
27 
28            if (-not $aResistante) { $verdict = 'À corriger : aucune méthode résistante' }
29            elseif ($aFaible) { $verdict = 'À durcir : méthodes faibles encore actives' }
30            else { $verdict = 'Conforme côté MFA' }
31        }
32        catch {
33            $verdict = 'Erreur de lecture : ' + $_.Exception.Message
34        }
35    }
36 
37    [pscustomobject]@{
38        Role      = $a.RoleDefinition.DisplayName
39        Compte    = $props['userPrincipalName']
40        Nom       = $props['displayName']
41        Nature    = $nature
42        Methodes  = $methodes
43        Verdict   = $verdict
44    }
45}
46 
47$rapport | Export-Csv -Path './audit-privileges.csv' -NoTypeInformation -Encoding UTF8
48$rapport | Group-Object Verdict | Select-Object Count, Name | Format-Table -AutoSize

To isolate the most urgent work, filter the CSV on accounts with no resistant method:

1Import-Csv -Path './audit-privileges.csv' | Where-Object { $_.Verdict -like 'À corriger*' } | Sort-Object Role | Format-Table Role, Compte, Methodes -AutoSize

The same view in the portal

Troubleshooting the audit

Extending coverage: policies and risk signals

The guide's third workstream is to apply Conditional Access to all identities and resources. In practice: block legacy authentication, require device compliance via Microsoft Intune, and enable Microsoft Entra ID Protection to enforce MFA at medium risk and credential reset at high risk.

Monitoring is part of the setup. Microsoft recommends exporting logs to Microsoft Sentinel or Azure Monitor, alerting on privileged role activations and scheduling recurring access reviews. An alert on every PIM activation turns an eligible role into an actionable signal.

AI agents: what the audit should already cover

Microsoft Entra Agent ID, the identity and authorisation framework for AI agents based on OAuth 2.0, MCP and A2A, has been generally available since April 2026, according to the Microsoft Entra releases and announcements page.

The pitfalls identified by the Zero Trust Assessment

The Zero Trust Assessment documentation flags two risks that your audit can check right now:

• without a “block unless approved” Conditional Access policy, every agent token request is allowed by default;
• a disabled agent or blueprint keeps its role assignments, group memberships and OAuth2 consents; reactivation restores all permissions without new approval.

The hygiene rule follows from this: clean up disabled objects and assign technical owners to every agent. For governance, see our article on AI agent governance with Agent 365 and Entra Agent ID.

On the incident response side, when an agent is confirmed compromised, its risk level moves to High, and a policy that blocks on “High Agent Risk” blocks it automatically. During the preview, Identity Protection for agents required an Entra ID P2 licence; check the current conditions before relying on it. The Agent ID Administrator (agent management) and Agent ID Developer (blueprint creation) roles let you separate responsibilities.

Frequently asked questions

Do I need a particular licence to use Entra Agent ID?

Not for Agent ID itself: it is available to all Entra customers. However, extending Entra's security features to agents, such as Conditional Access and governance, requires Microsoft Agent 365. This licence is included in Microsoft 365 E7 and is available as an add-on for E5, A5 and Business Premium.

Does a Conditional Access policy targeting an agent also cover its user account?

No. A policy targeting the agent identity does not cover the agent's user account, and vice versa. It also does not cover requests made on behalf of a user (OBO), which are evaluated against the user. Plan for separate policies.

Are synced passkeys ready for production?

Yes, they have been generally available in Microsoft Entra ID since the March 2026 announcement. For administration accounts, however, Microsoft's guide still favours device-bound passkeys or FIDO2 keys.

Where to start

Start with the script: in a single run, you know how many privileged accounts combine a standing role and weak MFA. Then treat those accounts before the rest of the population.

If your organisation already hosts AI agents, add now the inventory of their owners and the “block unless approved” policy. Otherwise, first finish the three human workstreams: they are the foundation your future agents will inherit. To go deeper into the architecture, see Microsoft Entra ID: architecture and key components and Zero Trust AI: securing agents with Microsoft.

Going further

• Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID: the deployment plan for phishing-resistant methods.
• Conditional Access for Agents in Microsoft Entra: licences, access patterns and limits of policies targeting agents.
• Configure agent identity security with the Zero Trust Assessment: concrete checks to run in the tenant, including orphaned agents.
• Governing Agent Identities - Microsoft Entra ID Governance: granting agents access through access packages, sponsors and owners.
• Microsoft Entra security for AI overview: risk scenarios and associated Entra controls.