Skip to main content
This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Federal Modernization Workbook · Book 15 · What

Chapter 04 — Help Desk Authority in Entra ID

The help desk’s authority model in Microsoft Entra ID: which built-in roles fit help desk work and whose credentials each can touch, scoping with administrative units and restricted management units, PIM activation, Temporary Access Pass and MFA re-registration, and the high-risk tasks that need a second approver.

A help desk is safe in Entra ID when the role it holds, not the caller on the line, decides whose account it can change, and when the changes that could hand an account to a stranger need two people besides the one making them.

NoteIn this chapter

The five built-in roles that cover most help desk identity work, what each can do, and whose credentials each can act on, with the corrections that Microsoft’s documentation forces on the older help desk design. How administrative units and restricted management units narrow those roles, and how the roles reach technicians through role-assignable groups and Privileged Identity Management (PIM). How to recover a user who has lost a sign-in method, with Temporary Access Pass and MFA re-registration, measured against NIST’s account recovery rules. Last, the high-risk tasks, why each needs a second approver, and the evidence every action leaves behind.

In Active Directory, help desk authority was a property of the tree. The help desk group got password-reset rights on an organizational unit, and every account placed in that OU was in scope. Nobody had to think about whose password could be reset, because the OU answered the question.

Microsoft Entra ID answers it differently, and the answer has three parts. The role decides what a technician can do. The target decides whether the role applies: most help desk roles can act only on users who hold no administrative role, or a short list of limited ones. The scope narrows the population further, to an administrative unit. A help desk design that gets any of the three wrong either can’t do its job or can do far more than it should.

Chapter 03 routed each request by the authority it needs. This chapter defines that authority inside Entra ID. Book 04 owns the privileged-access model the help desk sits inside, and Book 02, Chapter 05 owns the administrative-unit design; this chapter applies both to the help desk and doesn’t restate them. Appendix A gives the task-by-task reference.

A top-to-bottom flow. A slate card, assigned ticket, target user named, identity verified before any change, leads to an amber decision card asking what the target holds: roles, role-assignable group membership, or restricted administrative unit membership. The decision branches three ways. A green card, no admin role, help desk acts, using Password or Helpdesk Administrator or Authentication Administrator scoped to an administrative unit. An amber card, limited admin role, identity engineering acts, using a tenant-scoped role per Microsoft's table, because administrative-unit-scoped roles can't act on admins. A red card, privileged or protected, Tier 0 holder acts, meaning Privileged Authentication Administrator or the restricted unit's scoped admins, never the help desk. All three lead to a violet evidence card: ticket, audit entry and user notified, recording approver, executor, target, method and time.
Figure 1: The role that may act on a user’s credentials depends on what the target holds: the help desk acts on users with no admin role, identity engineering on limited admins, and only Tier 0 holders on privileged or protected accounts.

The built-in roles that fit help desk work

Microsoft Entra ID has no single “help desk” role that covers everything a help desk does, and the older design this chapter replaces was right about that. It was wrong about the details, and the details are where the risk sits. Five built-in roles carry most of the identity work. All five carry Microsoft’s privileged label.1

Role What it adds Whose credentials it can act on (tenant scope) Book 04 tier
Password Administrator Reset passwords; nothing else of note2 Users with no admin role, Directory Readers, Guest Inviter, Password Administrator3 Tier 2
Helpdesk Administrator Reset passwords, invalidate refresh tokens, manage service requests, monitor service health4 The Password Administrator set plus Helpdesk Administrator, Message Center Reader, Reports Reader and a few reader roles5 Tier 2
Authentication Administrator Set, reset and delete authentication methods (including passwords); require re-registration of MFA; create Temporary Access Pass for members; perform sensitive actions for some users67 Users with no admin role and some limited roles, including other Authentication Administrators and Password Administrators8 Tier 2
User Administrator Create users; update most properties; create and manage groups; assign licenses; reset passwords; delete and restore some users; can’t manage MFA9 Non-admins and limited admins, including Helpdesk, Groups and User Administrators10 Tier 2
Privileged Authentication Administrator Everything Authentication Administrator does, for every user including Global Administrators; delete or restore any user; update sensitive properties for all users11 Everyone, including members and owners of role-assignable groups12 Tier 0

The tiers are Book 04, Chapter 04’s. Privileged Authentication Administrator is the only one of the five that can reset a privileged administrator, which is exactly why it sits in Tier 0 and outside the help desk.

Whose account the role can touch

The “whose credentials” column is the part help desk designs most often get wrong. Microsoft publishes two matrices. “Who can reset passwords” lists, for each role that can reset passwords and invalidate refresh tokens, the roles of the users it can act on. “Who can perform sensitive actions” does the same for a list of sensitive properties: enabling or disabling the account, business and mobile phone, other emails, the password profile, the user principal name, the on-premises immutable ID, and deleting or restoring the user.13 Two rows matter more than the rest:

  • Members and owners of role-assignable groups can be reset only by Privileged Authentication Administrators and Global Administrators, even when they hold no role themselves.14 This is a deliberate protection: whoever could take over a member’s account would inherit the group’s role.
  • Users with a role scoped to a restricted management administrative unit are in the same protected class.15

Both tables describe tenant-scoped assignments. When the role is assigned at administrative-unit scope, Microsoft restricts it further: reading and modifying authentication methods, resetting passwords, modifying sensitive properties, and deleting or restoring accounts apply only to members of the unit who hold no administrator role.16 An AU-scoped help desk can’t reset a limited administrator inside its own unit; that request goes to identity engineering.

Capability is not authority

Several of these roles can do more than a help desk should, and the older design treated its prohibitions as if the platform enforced them. It doesn’t:

  • Authentication Administrator can delete, disable and enable users, and update their user principal name, for the users in its table.17 “The help desk doesn’t delete accounts” is a procedural rule for any technician holding it.
  • User Administrator can delete users, create guests and change licenses1819 and can reset passwords for limited administrators.20 The older design listed it as the broadest optional role for good reason.
  • Application Administrator can grant consent to delegated permissions and to application permissions outside Microsoft Graph, and can create enterprise applications.21 A help desk that activates it can technically do the one thing the help desk must never do. Book 04, Chapter 06 works through this case and replaces Application Administrator in the help desk with a custom role holding only microsoft.directory/servicePrincipals/appRoleAssignedTo/update, which manages user and group assignments to enterprise apps, scoped to one app or the whole tenant, and needs Entra ID P1 for each assignee.2223

Where the platform can’t enforce a boundary, the program enforces it twice: in the ticket, which must carry the approval, and in monitoring, which flags any audit event a help desk account produced outside an approved ticket (Evidence every action leaves).

Corrections to the older help desk design

The help desk guidance this chapter replaces made five claims that Microsoft’s documentation doesn’t support. Each one changes the design.

The older design said What Microsoft documents What changes
Helpdesk Administrator covers “only password resets and basic Microsoft 365 tasks” and isn’t used It resets passwords and invalidates refresh tokens for non-admins and several limited roles, and manages service requests and service health24 Helpdesk Administrator (or the narrower Password Administrator) is the right role for routine resets; the program uses it
Password reset rights map to Authentication Administrator The least-privileged role for resetting a non-admin’s password is Password Administrator25 Password resets use Password or Helpdesk Administrator; Authentication Administrator is for methods
Hybrid Identity Administrator resets the ImmutableID Hybrid Identity Administrator manages Entra Connect, cloud provisioning, pass-through authentication, password hash sync, seamless SSO and federation;26 it isn’t among the roles that can update onPremisesImmutableId (Authentication, User and Privileged Authentication Administrator, and Global Administrator, each for the users in Microsoft’s table)27 ImmutableID repair moves to identity engineering under a two-approver gate (below)
Role-assignable groups need Entra ID P2 Role-assignable groups need Entra ID P1; just-in-time activation through PIM needs P228 Licensing is P1 for the groups, P2 or Entra ID Governance for PIM
Authentication Administrator can “temporarily disable MFA” for a user The role manages a user’s methods, can require re-registration and can revoke remembered MFA; it can’t manage per-user MFA or tenant MFA settings, which belong to Authentication Policy Administrator2930 No “disable MFA” step; a user who has lost every method gets a Temporary Access Pass instead

The older design also scripted its ImmutableID procedure against the MSOnline module. MSOnline and the Azure AD PowerShell modules are deprecated; Microsoft Graph PowerShell replaces them.31 Every script in this book uses Graph PowerShell.

Scope: administrative units

Every help desk role in the table above except Privileged Authentication Administrator is normally assigned at administrative-unit scope in the program, following Book 02, Chapter 05. Authentication, Helpdesk, Password, User, Groups and License Administrator can all be assigned to an administrative unit; Application Administrator, Cloud Application Administrator and Hybrid Identity Administrator can’t.32 Each administrator assigned a role over a unit needs Entra ID P1; members need only Entra ID Free, unless the unit’s membership is dynamic, in which case each member needs P1.3334

The old AD habit translates directly. Where the help desk had reset rights on OU=Field-Offices, it now holds Password Administrator over a dynamic administrative unit whose rule selects the field-office population from an HR-sourced attribute. Two things don’t translate. An administrative unit limits what a technician can change, not what they can see,35 and an administrative unit can’t be nested, so “region inside department” is a naming convention.

Restricted management units for the accounts the help desk must not reset

Some accounts should be out of the help desk’s reach even when they hold no role: executives, their assistants, and other high-value targets. Microsoft’s own example is the chief executive’s account, which a tenant-wide Helpdesk Administrator could otherwise reset.36 A restricted management administrative unit solves this. Only administrators with a role assigned at the scope of that unit can change its members’ Entra properties; tenant-scoped Global Administrators and Privileged Role Administrators can’t edit the objects, though they can manage the unit itself, including assigning themselves a role over it, and those actions are audited.37

The program’s pattern for executive support:

  1. Put the executive accounts and their devices in a restricted management unit, decided at creation because the setting can’t be changed later.3839
  2. Assign Authentication Administrator and Password Administrator over that unit to a small executive-support group, eligible through PIM, with approval required.
  3. Leave the general help desk without any assignment over it. A reset request for an executive reaches the help desk, fails the target check at the top of this chapter, and routes to executive support.

Don’t put the help desk technicians themselves in a restricted management unit. Users and groups in one can’t be managed by Entra ID Governance features, including PIM, entitlement management, lifecycle workflows and access reviews.40 The technicians are protected a different way, below.

How the roles reach a technician

The older design called its mechanism a “Privileged Access Group.” That was Microsoft’s name, until January 2023, for what is now PIM for Groups.41 The program uses Book 04, Chapter 04’s pattern instead of one group holding every role:

  • One role-assignable group per role and scope, named PRV-T2-<role>-<AU> (for example PRV-T2-PasswordAdmin-AU-FieldOps). The group holds an eligible assignment of the role at the unit’s scope. Technicians are members of the group and activate the role in PIM.
  • Membership through an access package with approval, expiry and review (Book 04, Chapter 09), so onboarding a technician is itself an approved, recorded request.
  • A custom role for application assignments, held the same way, in place of Application Administrator.

The role-assignable group does two jobs. It carries the role, and it protects its members. A role-assignable group can’t have dynamic membership or nested groups, its isAssignableToRole property is set only at creation, and a tenant can have at most 500 of them.42 Because only Privileged Authentication Administrators and Global Administrators can reset the credentials of a role-assignable group’s members,43 one technician can’t reset another technician’s password and inherit their access. That matters, because Helpdesk Administrators can otherwise reset other Helpdesk Administrators, and Authentication Administrators other Authentication Administrators.44

PIM settings for help desk roles

PIM settings are defined per role, and every assignment of a role follows that role’s settings.45 The help desk therefore inherits Book 04’s Tier 2 values (Book 04, Appendix B): eligible only, an 8-hour activation ceiling, justification and ticket number required, eligibility expiring after 180 days, and PIM approval not required under a documented risk acceptance. Four points apply to the help desk in particular.

  • The approval lives in the ticket. Book 04’s risk acceptance for Tier 2 rests on scoping and on role-assignable groups protecting their members. The approval a help desk action needs, such as the supervisor’s approval of an MFA reset, is recorded in the ticket, not in PIM. High-risk tasks add a second approver, also recorded in the ticket (below).
  • The ticket number is information only. PIM can require a ticket number on activation, but it doesn’t check the number against any ticketing system.46 The older design promised that activations without a valid request number would be flagged automatically. That only happens if the agency builds the correlation, which the program does in its SIEM: every activation’s ticket field is joined to the ITSM record and an unmatched number raises an alert.
  • Shorter is possible but tenant-wide. A help desk working ticket by ticket rarely needs eight hours, and the activation maximum can be anything from one to 24 hours.47 Because the setting is per role, shortening Password Administrator to two hours shortens it for every holder in the tenant. Agree any change with the owners of Book 04’s role settings.
  • Approvers can’t approve themselves. Where a role does require approval, the platform blocks self-approval, approvers have 24 hours to act, and an unanswered request expires.48

Hybrid Identity Administrator and Application Administrator stay in Book 04’s Tier 1, with identity engineering, behind approval by the Tier 1 approver group. The help desk doesn’t hold them.

Onboarding and offboarding technicians

Onboarding is an access-package request for the technician’s role groups, approved by the identity governance officer on the service desk supervisor’s request. PIM training and the verification check come first and are on record before the access package is requested (Book 16, Chapter 09), so no technician is made eligible, or activates a role, untrained. The program reviews help desk role membership quarterly, as Book 04 sets for Tier 2: the reviewers are the role owner (the administrative unit’s department lead) and the security office, with removal on non-response. The supervisor’s view of each technician’s continued need is an input to that review, not the review itself.

Offboarding is faster and needs no governance approval, because removing access never increases risk: the supervisor’s request removes the technician from the role groups. If the technician has an active activation at the time, identity engineering removes the active assignment as well, then revokes the technician’s sessions.

Identity proofing before any credential action

The most common attack on a help desk is a phone call. CISA’s advisory on the Scattered Spider group describes actors calling IT help desk staff, posing as employees, to get passwords reset or MFA moved to a device they control, and it recommends phishing-resistant MFA and continued training against voice phishing.49 Every role in this chapter is only as safe as the check the technician performs before using it.

NIST SP 800-63B-4 (July 2025) treats a lost authenticator as account recovery. It recognizes four recovery methods: saved recovery codes, issued recovery codes, recovery contacts, and repeated identity proofing. To recover an account that authenticates at AAL2, it calls for two recovery codes delivered by different methods, one recovery code plus a bound single-factor authenticator, or repeated identity proofing if the account was identity-proofed. In every case, recovery must send a notification to the subscriber.50

For a workforce that was proofed at hiring, the program’s recovery rule follows the last option:

  1. Re-proof, don’t interview. The technician confirms identity against the record the agency already holds: in person with the PIV card, or by a supervised video session against the HR-sourced identity. Knowledge questions, the caller’s own callback number, and email are never enough on their own.
  2. Check the target before the method. If the user holds any role, is a member or owner of a role-assignable group, or sits in a restricted management unit, the help desk stops and routes the request, as the first figure in this chapter shows.
  3. Notify the user through a channel other than the one the request came on, every time a credential or method changes.

Microsoft Entra ID also offers self-service account recovery for a user who has lost every method: a third-party identity verification provider checks a government-issued ID, Verified ID Face Check matches the user to it, and the user is issued a Temporary Access Pass to register new methods.51 The program holds it until it is available in GCC: Microsoft lists Verified ID itself as supported in GCC but not GCC High,52 and doesn’t state government-cloud availability for account recovery, so for this feature it is not yet specified.

Temporary Access Pass and MFA re-registration

When a user has lost their only strong method, the help desk has two tools, and the older design had neither.

Require re-register MFA deactivates the user’s hardware OATH tokens and deletes their phone numbers, Microsoft Authenticator registrations and software OATH tokens; the user is asked to set up a new method at the next sign-in.53 Revoke sessions invalidates the user’s refresh tokens and forces reauthentication everywhere.54 Re-registration alone leaves a gap: the next sign-in, whoever makes it, gets to register the new method.

A Temporary Access Pass closes that gap. It is a time-limited passcode, for single or multiple use, that lets a user sign in and register a new method, including a passkey, without the method they lost.55 Its controls shape the procedure:

  • Who can issue it. Authentication Administrators can create, delete and view a pass for members, not for themselves; Privileged Authentication Administrators can do so for admins too. The pass method must be enabled in the authentication methods policy, which takes Authentication Policy Administrator, and only users the policy includes can sign in with one.56
  • Lifetime. The tenant sets a minimum, maximum and default between 10 minutes and 30 days; the defaults are one hour minimum and default and eight hours maximum. One-time use can be enforced tenant-wide, and each user can have only one pass at a time.57
  • Ten minutes to register. With a one-time pass, the user must finish registering a passwordless method within 10 minutes of signing in.58
  • Expiry doesn’t end the session. Tokens issued during a pass sign-in are capped at the pass’s expiry when issued, but expiry doesn’t invalidate sessions already established; sign-in frequency in Conditional Access governs how long access lasts.59
  • Limits. A pass can’t be used with the NPS extension or the AD FS adapter, and can’t be issued to external guests.60

The program’s recovery sequence, executed by an Authentication Administrator scoped to the user’s unit against a supervisor-approved ticket:

  1. Re-proof the user and run the target check above.
  2. Revoke the user’s sessions.
  3. Delete the lost method, or require re-registration if the user has lost several.
  4. Issue a one-time pass with the shortest lifetime the handover allows, delivered to the verified person, never to an email address or a number supplied on the call.
  5. Stay with the user while they register a phishing-resistant method, then confirm the old method is gone. Microsoft notes that users replacing lost credentials should remove the old ones.61
  6. Notify the user, and close the ticket with the evidence in Evidence every action leaves.

Appendix B turns this sequence and its neighbors (a lost passkey, a Windows Hello for Business reset, a replaced device, a BitLocker recovery key, an emergency access account incident and a Conditional Access block) into runbooks with copy-paste commands, escalation and a quarterly help-desk simulation.

The pass policy settings (one-time use, the lifetime ceiling, which groups may use a pass) are policy, not help desk work. They belong to the authentication policy owners in Book 04.

The high-risk tasks and why they need a second approver

A task is high-risk in the program’s design when one person could use it to take over an identity, break the link between an identity and its source of truth, or open an application to the wrong people, and when the platform can’t stop the misuse by itself. For those tasks a single approval isn’t enough. NIST SP 800-53 asks organizations to identify the duties that must be separated and to define access authorizations that support the separation (AC-5), and to log the use of privileged functions (AC-6(9)).62 The program’s answer is two approvers besides the executor, both recorded in the ticket before any role is activated.

A top-to-bottom flow. A slate request card, high-risk task on an assigned ticket, naming the target, the exact change, the reason and the values supplied, leads to an amber identity proofing card: requester verified out of band, never by email or a callback number the caller gives. That leads to a blue first approver card, the owner of the change, a supervisor or identity engineering lead, and then to a violet second approver card, independent of the first, the governance officer or security. A red blocked card, pressure to skip a step, route to the emergency change process, has a dashed red arrow labeled not a bypass pointing back to identity proofing. After the second approver, a green PIM card: activate the narrowest role, justification carries the ticket number, shortest window the task needs. Then a green execute and verify card: change, re-read, deactivate, stop on any mismatch with the ticket. Last, a violet evidence card: ticket, PIM record and audit entry, which the SIEM joins, and the user is notified.
Figure 2: A high-risk task in the program’s design: the requester is verified out of band, two independent approvers sign the ticket, and only then is the narrowest role activated, the change made and re-read, and the evidence joined in the SIEM.
Task Why it’s high-risk Who executes First approver Second approver
Credential or method reset, or a pass, for an account the help desk can’t touch (a privileged role, a role-assignable group member, a restricted unit member) Hands over an account that controls others Privileged Authentication Administrator (Tier 0), or the restricted unit’s scoped admins Account owner’s manager Security office
ImmutableID or hard-match repair A wrong mapping links a cloud account to the wrong on-premises object, which then becomes its source of authority63 Identity engineering Identity engineering lead Identity governance officer
Delete, disable or restore an account outside the HR-driven lifecycle Destroys or revives access without the authoritative record User Administrator, in identity engineering Account owner’s manager Identity governance officer
Enterprise-app assignment to a R1 (high-risk) application Opens high-risk data to a group Help desk, custom assignment role Application owner Identity governance office, as the second approval stage for a R1 (high-risk) application, per Book 04, Chapter 06
Bulk change (many users, one request) One mistake repeated at scale Automation, under Book 13, Chapter 10’s change classes Change owner Change advisory board

Admin consent isn’t on the list because the help desk never performs it at all; it triages and escalates (Book 04, Chapter 06).

Why ImmutableID repair left the help desk

The older design let help desk technicians reset a user’s ImmutableID through PowerShell once two people had approved. The approvals were right; the executor and the method weren’t. Microsoft’s documentation explains why the task is dangerous and where it should be fixed:

  • Matching happens on new objects only. Entra Connect evaluates hard match (on the source anchor, which becomes onPremisesImmutableId) and soft match (on UPN or primary SMTP address) only when a new object arrives from AD; changing an existing object so it matches produces an error instead.64
  • Fix it at the source. For the common duplicate-object conflict, Microsoft’s fix is to set the on-premises user’s mS-DS-ConsistencyGuid to the existing cloud user’s ImmutableID, so the next sync makes the correct hard match.65 That is an AD change, made by the AD and identity engineering teams.
  • Synced objects resist cloud edits. For synced users, whether a property can be updated in Microsoft Graph also depends on the source of authority and whether sync is enabled.66 Writing onPremisesImmutableId from the cloud is mainly a way to prepare a cloud-only account to be taken over.
  • The platform now blocks risky matches. From July 1, 2026, Entra ID blocks a hard match when the target cloud account already has onPremisesObjectIdentifier set, or holds or is eligible for a privileged role, and Microsoft cautions against using hard match as a general repair tool.67
  • Hard match should usually be off. Microsoft advises blocking hard matching unless it’s needed to take over cloud-only accounts, and turning the block back on once the match is done.68

So the program treats an ImmutableID mismatch as an identity engineering change: the help desk detects it (sign-in failures, a duplicate object, a stale last-sync time) and escalates with the evidence; identity engineering decides whether the fix is in AD or in the cloud, and executes it under the two approvals. Appendix A has the detection steps and a read-only comparison script.

What the second approver checks

A second approver who rubber-stamps adds nothing. The program asks the second approver to confirm three things the first may not:

  1. The requester was verified by the method in Identity proofing, and the record of it is in the ticket.
  2. The change is exactly specified: the target’s object ID, not just a display name; the values to set, supplied by the authoritative source and not worked out by the executor; and the rollback.
  3. The urgency is real. A caller who presses for speed, or a manager who asks the technician to skip the queue, is routed to the supervisor’s emergency change process, which has its own approvals. Urgency is never a reason to skip the second approver.

Evidence every action leaves

Each help desk action produces three records, and the evidence contract in Book 12, Chapter 02 needs all three joined on the target’s identity and the time:

  • The ticket: requester, verification method, approvers with timestamps, target object ID, the exact change, the executor, and the result.
  • The PIM record: the activation request, its justification and ticket number, any approval, and the activation and deactivation times. PIM writes these to the audit log under activities such as “Add member to role completed (PIM activation).”69
  • The directory audit entry for the change itself, for example “Reset password,” “Admin deleted security info,” “Admin registered security info,” “Update user,” “Delete user” or “Add app role assignment to group.”70

Entra ID keeps audit and sign-in logs for 30 days with P1 or P2 (seven with Free), and longer retention means routing them out through Azure Monitor or using Purview Audit.71 The program streams them to the SIEM (Book 12), where three rules run continuously:

  1. Any privileged activation whose ticket number doesn’t match an assigned ticket in the ITSM tool.
  2. Any directory change by a help desk account that has no matching ticket.
  3. Any action the help desk may never take (a consent grant, a role assignment, a Conditional Access change) attributed to a help desk account, alerted immediately to the security operations center.

Help desk technicians read logs for triage; they don’t export, copy or delete them. The least-privileged role for reading audit and sign-in logs is Reports Reader,72 not Application Administrator as the older design assumed, and seeing which Conditional Access policies applied to a sign-in also needs permission to read the policies, which Security Reader provides.73

The authority boundary

The help desk’s boundary, both ways, is set in Book 04, Chapter 06: it executes approved work and never decides. This chapter adds the identity-specific edges:

The help desk may The help desk may not
Reset passwords and methods, and issue a Temporary Access Pass, for users with no admin role in its units Act on an admin, a role-assignable group member, or a restricted unit member
Revoke a user’s sessions during recovery or a suspected compromise Disable MFA, change authentication method policy, or edit Conditional Access
Detect sync and ImmutableID problems and escalate with evidence Write onPremisesImmutableId, or change sync rules or Entra Connect configuration
Assign approved groups to enterprise apps with the custom assignment role Hold Application Administrator, or grant any consent
Read sign-in and audit logs inside an assigned ticket Export, copy or retain log data outside the SIEM

External partner persons stay inside the same boundary. The help desk may reset a partner guest’s invitation on the sponsor’s request, but suspension, termination, guest approval and any change to the partner configuration are decided by the agency business owner and executed outside the help desk, and drift on the partner configuration is a finding for identity engineering and the IGO (Book 03, Chapter 15; Appendix A).

Who staffs the help desk and cloud services tiers, and how their work is measured, is Chapter 10’s subject. The catalog items that put these tasks in front of users are Chapter 05’s.

Putting the authority model in place

The sections above describe a configuration: one role-assignable group per role and scope holding an eligible, administrative-unit-scoped assignment; a restricted management unit for executive support; the custom application-assignment role in place of Application Administrator; the SIEM rules; and the recovery sequence. Moving a help desk from standing portal rights onto it is an enforcement change, because a technician who held a tenant-wide role yesterday can reset fewer accounts today. This section gives that move the workbook’s implementation conventions (Book 00, Appendix D), pointing back to where the chapter already covers each part.

Authority: Microsoft-recommended for the least-privileged role per task, for scoping roles with administrative units and restricted management units, and for removing a lost method after recovery (the Learn pages cited above, read Oct 21 and Nov 9, 2026, and re-read for the Temporary Access Pass facts on Nov 11, 2026); Microsoft’s Zero Trust guidance also recommends restricting Temporary Access Pass to one-time use.74 Mandated where the system’s baseline selects AC-5 and AC-6(9), which ask for separated duties and logged use of privileged functions (above). Risk-based recommended, the program’s position: one group per role and scope, the restricted unit for executives, the two-approver rule and the ticket-to-activation correlation in the SIEM. Applies: License-dependent: Entra ID P1 for each administrator assigned a role over an administrative unit or a restricted management unit, and for the custom role’s assignees; Entra ID P2 or Entra ID Governance for PIM (above). Environment-dependent: Office 365 GCC pairs with Microsoft Entra ID in the commercial cloud, and GCC High and DoD with Microsoft Entra ID in Azure Government;75 Learn’s government feature table lists built-in delegated administration, role-based access control and PIM as available in Azure for US Government, but doesn’t list administrative units, restricted management units or Temporary Access Pass separately, so their availability in GCC High and DoD is not yet specified.76

How-template step Where this chapter covers it, or what it adds
Prerequisites The licenses and government-cloud status above; Book 04’s tiers and Tier 2 PIM settings; Book 02, Chapter 05’s administrative units built and populated; technicians trained before they are made eligible (Onboarding and offboarding technicians)
Pilot One administrative unit and its technicians first, with identity engineering keeping its current rights until the pilot unit’s tickets close inside the scoped roles
Report-only or audit phase Entra role assignments have no report-only mode. The audit phase runs the SIEM rules in Evidence every action leaves for two weeks while the old standing assignments still exist, listing every action a technician took that the new scoped role wouldn’t have allowed, before any standing assignment is removed
Enforcement Eligible assignments through the role groups, then removal of standing and tenant-wide help desk assignments, ring by ring (change safety, below)
Rollback Re-add the technician to the previous role group, or re-create a removed assignment from the export taken before the change; a Privileged Role Administrator does it through PIM against the change record, in minutes. A restricted management unit can’t be turned back into an ordinary one, because the setting is fixed at creation (above); its rollback is moving the members out
Exclusions Emergency access accounts hold Global Administrator, so no help desk role can reset them (Whose account the role can touch); they stay out of every help desk group and administrative unit, and an emergency access incident goes to Appendix B, Runbook 5. No technician is excluded from the role-group model; an exception is a named, expiring assignment approved by the security office
Telemetry PIM activation records, directory audit entries and the three SIEM rules (above)
Evidence The checklist below
Day-two ownership Identity engineering owns the role groups and the restricted unit; the service desk supervisor raises technician membership requests; the quarterly Tier 2 review and the cadence in Chapter 12 keep it current. Drift is a standing help desk assignment, a help desk account acting without a ticket, or a role-group member with no access package assignment

Change safety

Ring Scope Exit criteria
0 Identity engineering’s own test technician accounts Each help desk task in Appendix A completed inside the scoped role, and each forbidden task refused
1 One administrative unit and its technicians Two weeks with no ticket that couldn’t be closed in the scoped role, and no SIEM rule hit left unexplained
2 The remaining administrative units, a few at a time The same criteria, unit by unit
3 Standing and tenant-wide help desk assignments removed; executive accounts moved into the restricted unit No standing help desk assignment in the export; the executive-support group completes a test reset, and the general help desk’s attempt fails the target check
  • Emergency access: outside every help desk scope; the quarterly emergency access drill (Chapter 12) confirms the accounts still sign in after the change.
  • Change window: business hours with identity engineering on hand, so a ticket the new role can’t close is escalated the same day; approved by the change advisory board as a normal change.
  • Backout triggers: set before each ring, for example escalations from the help desk to identity engineering above the level the pilot showed, or a recovery that can’t be completed within its service level.
  • Post-change validation: an in-scope test reset that succeeds and an out-of-scope one that is refused, for each unit, recorded on the change.

Control states.

State This page Evidence
Designed The role table, the scope and restricted-unit pattern, and the boundary table This chapter as adopted by the identity governance officer, and the list of role groups
Configured Role groups, eligible scoped assignments, the custom role and the restricted unit An export of role assignments and eligibility schedules by scope, and of the restricted unit’s members
Enforced Standing and tenant-wide help desk assignments removed (ring 3) The export showing no active help desk assignment outside PIM, and the exception list
Evidenced The post-change validation, and the SIEM rules firing on a deliberate test Test records: an in-scope reset that succeeded, an out-of-scope reset that was refused, and a test activation with no ticket that raised the alert
Operated The quarterly review of help desk role membership; the SIEM rules running The review records, the alert history and the cadence task’s closure

A finding this page addresses is ready for closure when every applicable state has evidence; the authorizing official or assessor decides.

Evidence checklist

NoteAssessment mapping
  • Microsoft Zero Trust pillar: Identity
  • CISA ZTMM pillar: Identity
  • Depends on: Book 04’s privileged-access tiers and PIM (Identity); Book 12’s SIEM for the ticket correlation (SecOps); the HR-sourced attributes that populate dynamic administrative units (Book 03)
  • Attack chain interrupted: a social-engineering call to the help desk that ends in a reset or a new method for the caller (Initial Access, Credential Access), and one technician’s account used to take over others (Privilege Escalation, Lateral Movement)
TipContinue the book

← Previous: Chapter 03 — Intake, Triage and Routing · Book index · Next: Chapter 05 — The Service Catalogs: ITSM and Teams Telephony →

  1. Microsoft Learn, “Microsoft Entra built-in roles,” entries for Authentication Administrator, Hybrid Identity Administrator, Password Administrator, Privileged Authentication Administrator and User Administrator, https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference (accessed Oct 21, 2026).↩︎

  2. Microsoft Learn, “Microsoft Entra built-in roles,” entries for Authentication Administrator, Hybrid Identity Administrator, Password Administrator, Privileged Authentication Administrator and User Administrator, https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference (accessed Oct 21, 2026).↩︎

  3. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  4. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  5. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  6. Microsoft Learn, “Microsoft Entra built-in roles,” entries for Authentication Administrator, Hybrid Identity Administrator, Password Administrator, Privileged Authentication Administrator and User Administrator, https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference (accessed Oct 21, 2026).↩︎

  7. Microsoft Learn, “Configure Temporary Access Pass to register passwordless authentication methods,” https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass (accessed Oct 21, 2026).↩︎

  8. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  9. Microsoft Learn, “Microsoft Entra built-in roles,” entries for Authentication Administrator, Hybrid Identity Administrator, Password Administrator, Privileged Authentication Administrator and User Administrator, https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference (accessed Oct 21, 2026).↩︎

  10. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  11. Microsoft Learn, “Microsoft Entra built-in roles,” entries for Authentication Administrator, Hybrid Identity Administrator, Password Administrator, Privileged Authentication Administrator and User Administrator, https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference (accessed Oct 21, 2026).↩︎

  12. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  13. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  14. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  15. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  16. Microsoft Learn, “Assign Microsoft Entra roles,” section “Assign roles with administrative unit scope,” https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-assign-roles (accessed Oct 21, 2026).↩︎

  17. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  18. Microsoft Learn, “Microsoft Entra built-in roles,” entries for Authentication Administrator, Hybrid Identity Administrator, Password Administrator, Privileged Authentication Administrator and User Administrator, https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference (accessed Oct 21, 2026).↩︎

  19. Microsoft Learn, “Least privileged roles by task in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/delegate-by-task (accessed Oct 21, 2026).↩︎

  20. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  21. Microsoft Learn, “Least privileged roles by task in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/delegate-by-task (accessed Oct 21, 2026).↩︎

  22. Microsoft Learn, “Create custom roles to manage enterprise apps in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/custom-enterprise-apps (accessed Oct 21, 2026).↩︎

  23. Microsoft Learn, “Create a custom role in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/custom-create, and “Enterprise application permissions for custom roles in Microsoft Entra ID,” section “Assigning users or groups to an application,” https://learn.microsoft.com/entra/identity/role-based-access-control/custom-enterprise-app-permissions (accessed Nov 9, 2026).↩︎

  24. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  25. Microsoft Learn, “Least privileged roles by task in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/delegate-by-task (accessed Oct 21, 2026).↩︎

  26. Microsoft Learn, “Microsoft Entra built-in roles,” entries for Authentication Administrator, Hybrid Identity Administrator, Password Administrator, Privileged Authentication Administrator and User Administrator, https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference (accessed Oct 21, 2026).↩︎

  27. Microsoft Learn, “Working with users in Microsoft Graph,” section “Sensitive actions,” https://learn.microsoft.com/graph/api/resources/users (accessed Oct 21, 2026).↩︎

  28. Microsoft Learn, “Use Microsoft Entra groups to manage role assignments,” https://learn.microsoft.com/entra/identity/role-based-access-control/groups-concept (accessed Oct 21, 2026).↩︎

  29. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  30. Microsoft Learn, “Microsoft Entra built-in roles,” entries for Authentication Administrator, Hybrid Identity Administrator, Password Administrator, Privileged Authentication Administrator and User Administrator, https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference (accessed Oct 21, 2026).↩︎

  31. Microsoft Learn, “Upgrade from Azure AD PowerShell to Microsoft Graph PowerShell,” https://learn.microsoft.com/powershell/microsoftgraph/migration-steps (accessed Oct 21, 2026).↩︎

  32. Microsoft Learn, “Assign Microsoft Entra roles,” section “Assign roles with administrative unit scope,” https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-assign-roles (accessed Oct 21, 2026).↩︎

  33. Microsoft Learn, “Assign Microsoft Entra roles,” section “Assign roles with administrative unit scope,” https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-assign-roles (accessed Oct 21, 2026).↩︎

  34. Microsoft Learn, “Administrative units in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/administrative-units (accessed Oct 21, 2026).↩︎

  35. Microsoft Learn, “Administrative units in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/administrative-units (accessed Oct 21, 2026).↩︎

  36. Microsoft Learn, “Restricted management administrative units in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-restricted-management (accessed Oct 21, 2026).↩︎

  37. Microsoft Learn, “Restricted management administrative units in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-restricted-management (accessed Oct 21, 2026).↩︎

  38. Microsoft Learn, “Restricted management administrative units in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-restricted-management (accessed Oct 21, 2026).↩︎

  39. Microsoft Learn, “Create or delete administrative units,” section “Create an administrative unit” (the restricted management setting), https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-manage, and “Add users, groups, or devices to an administrative unit,” https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-members-add (accessed Nov 9, 2026).↩︎

  40. Microsoft Learn, “Restricted management administrative units in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-restricted-management (accessed Oct 21, 2026).↩︎

  41. Microsoft Learn, “Privileged Identity Management (PIM) for Groups,” https://learn.microsoft.com/entra/id-governance/privileged-identity-management/concept-pim-for-groups (accessed Oct 21, 2026).↩︎

  42. Microsoft Learn, “Use Microsoft Entra groups to manage role assignments,” https://learn.microsoft.com/entra/identity/role-based-access-control/groups-concept (accessed Oct 21, 2026).↩︎

  43. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  44. Microsoft Learn, “Privileged roles and permissions in Microsoft Entra ID (preview),” sections “Compare authentication roles,” “Who can reset passwords” and “Who can perform sensitive actions,” https://learn.microsoft.com/entra/identity/role-based-access-control/privileged-roles-permissions (accessed Oct 21, 2026).↩︎

  45. Microsoft Learn, “Configure Microsoft Entra role settings in PIM,” https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings (accessed Oct 21, 2026).↩︎

  46. Microsoft Learn, “Configure Microsoft Entra role settings in PIM,” https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings (accessed Oct 21, 2026).↩︎

  47. Microsoft Learn, “Configure Microsoft Entra role settings in PIM,” https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings (accessed Oct 21, 2026).↩︎

  48. Microsoft Learn, “Approve or deny requests for Microsoft Entra roles in Privileged Identity Management,” https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-approval-workflow (accessed Oct 21, 2026).↩︎

  49. Cybersecurity and Infrastructure Security Agency, AA23-320A, Scattered Spider, November 16, 2023 (updated July 29, 2025), https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a (accessed Oct 21, 2026).↩︎

  50. National Institute of Standards and Technology, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, July 2025, section 4.2, “Account Recovery,” https://pages.nist.gov/800-63-4/sp800-63b.html (accessed Oct 21, 2026); publication record https://csrc.nist.gov/pubs/sp/800/63/b/4/final.↩︎

  51. Microsoft Learn, “Account recovery overview,” https://learn.microsoft.com/entra/identity/authentication/concept-account-recovery-overview, and “Enable and configure account recovery in Microsoft Entra ID,” section “Prerequisites,” https://learn.microsoft.com/entra/identity/authentication/how-to-account-recovery-enable (accessed Nov 9, 2026).↩︎

  52. Microsoft Learn, “What’s new in Microsoft Entra Verified ID,” September 2025 (“Entra Verified ID is supported on Microsoft GCC environments … GCC only and not GCC High”), https://learn.microsoft.com/entra/verified-id/whats-new (accessed Nov 9, 2026).↩︎

  53. Microsoft Learn, “Manage user authentication methods for Microsoft Entra multifactor authentication,” section “Manage user authentication options,” https://learn.microsoft.com/entra/identity/authentication/howto-mfa-userdevicesettings (accessed Oct 21, 2026).↩︎

  54. Microsoft Learn, “Manage user authentication methods for Microsoft Entra multifactor authentication,” section “Manage user authentication options,” https://learn.microsoft.com/entra/identity/authentication/howto-mfa-userdevicesettings (accessed Oct 21, 2026).↩︎

  55. Microsoft Learn, “Configure Temporary Access Pass to register passwordless authentication methods,” https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass (accessed Oct 21, 2026).↩︎

  56. Microsoft Learn, “Configure Temporary Access Pass to register passwordless authentication methods,” https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass (accessed Oct 21, 2026).↩︎

  57. Microsoft Learn, “Configure Temporary Access Pass to register passwordless authentication methods,” https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass (accessed Oct 21, 2026).↩︎

  58. Microsoft Learn, “Configure Temporary Access Pass to register passwordless authentication methods,” https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass (accessed Oct 21, 2026).↩︎

  59. Microsoft Learn, “Configure Temporary Access Pass to register passwordless authentication methods,” https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass (accessed Oct 21, 2026).↩︎

  60. Microsoft Learn, “Configure Temporary Access Pass to register passwordless authentication methods,” https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass (accessed Oct 21, 2026).↩︎

  61. Microsoft Learn, “Configure Temporary Access Pass to register passwordless authentication methods,” https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass (accessed Oct 21, 2026).↩︎

  62. FedRAMP, “Access Control” (NIST SP 800-53 Rev. 5 controls, catalog release 5.2.0), AC-5 and AC-6(9), https://fedramp.gov/2026/reference/controls/access-control/ (accessed Oct 21, 2026).↩︎

  63. Microsoft Learn, “Configure Microsoft Entra Connect for an existing tenant,” sections “Hard match vs soft match,” “Block hard match in Microsoft Entra ID” and “Hard match security protections,” https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant (accessed Oct 21, 2026).↩︎

  64. Microsoft Learn, “Configure Microsoft Entra Connect for an existing tenant,” sections “Hard match vs soft match,” “Block hard match in Microsoft Entra ID” and “Hard match security protections,” https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant (accessed Oct 21, 2026).↩︎

  65. Microsoft Learn, “Configure Microsoft Entra Connect for an existing tenant,” sections “Hard match vs soft match,” “Block hard match in Microsoft Entra ID” and “Hard match security protections,” https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant (accessed Oct 21, 2026).↩︎

  66. Microsoft Learn, “Update user” (Microsoft Graph v1.0), https://learn.microsoft.com/graph/api/user-update (accessed Oct 21, 2026).↩︎

  67. Microsoft Learn, “Configure Microsoft Entra Connect for an existing tenant,” sections “Hard match vs soft match,” “Block hard match in Microsoft Entra ID” and “Hard match security protections,” https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant (accessed Oct 21, 2026).↩︎

  68. Microsoft Learn, “Configure Microsoft Entra Connect for an existing tenant,” sections “Hard match vs soft match,” “Block hard match in Microsoft Entra ID” and “Hard match security protections,” https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant (accessed Oct 21, 2026).↩︎

  69. Microsoft Learn, “Microsoft Entra audit log activity reference,” https://learn.microsoft.com/entra/identity/monitoring-health/reference-audit-activities (accessed Oct 21, 2026).↩︎

  70. Microsoft Learn, “Microsoft Entra audit log activity reference,” https://learn.microsoft.com/entra/identity/monitoring-health/reference-audit-activities (accessed Oct 21, 2026).↩︎

  71. Microsoft Learn, “Microsoft Entra data retention,” https://learn.microsoft.com/entra/identity/monitoring-health/reference-reports-data-retention (accessed Oct 21, 2026).↩︎

  72. Microsoft Learn, “Least privileged roles by task in Microsoft Entra ID,” https://learn.microsoft.com/entra/identity/role-based-access-control/delegate-by-task (accessed Oct 21, 2026).↩︎

  73. Microsoft Learn, “View applied Conditional Access details in the Microsoft Entra activity logs,” section “Prerequisites,” https://learn.microsoft.com/entra/identity/monitoring-health/how-to-view-applied-conditional-access-policies (accessed Oct 21, 2026).↩︎

  74. Microsoft Learn, “Configure Microsoft Entra for Zero Trust: Protect identities and secrets,” section “Restrict Temporary Access Pass to Single Use,” https://learn.microsoft.com/entra/fundamentals/zero-trust-protect-identities (accessed Nov 11, 2026).↩︎

  75. Microsoft Learn, “Cloud feature availability for US Government customers,” section “Microsoft 365 integration” (Office 365 GCC is paired with Microsoft Entra ID in Azure; Office 365 GCC High and DoD with Microsoft Entra ID in Azure Government), https://learn.microsoft.com/azure/security/fundamentals/feature-availability (accessed Nov 11, 2026).↩︎

  76. Microsoft Learn, “Microsoft Entra feature availability” (Azure for US Government), table “Microsoft Entra ID,” rows “Role-based access control (RBAC),” “Delegated administration—built-in roles” and “Privileged Identity Management (PIM),” https://learn.microsoft.com/entra/identity/authentication/feature-availability (accessed Nov 11, 2026).↩︎

Back to top