A protected account starts with a trustworthy device
An administrator can use excellent MFA and still expose a session from a compromised computer. A privileged access workstation reduces opportunities to steal credentials, intercept actions or reuse sessions. Conditional Access controls access conditions; Privileged Identity Management (PIM) limits when privileges are available. These controls need to work together.
This guide proposes an architecture for human Microsoft 365 administrators. Application identities, unattended scripts and on-premises Active Directory administration need additional controls. Group names and durations below are examples to adapt.
1. Inventory administrative access paths
An everyday email account should not be a shortcut for privileged work. A separate browser profile helps organize sessions but does not create a security boundary against a compromised operating system.
- Inventory active and eligible Entra roles, role-assignable groups, guests and partner delegations.
- List the portals actually used: Entra, Exchange, Intune, Defender, SharePoint, Purview and Azure.
- Include Microsoft Graph PowerShell, Exchange Online PowerShell, third-party tools and their authentication resources.
- Identify emergency accounts, PIM approvers and the people able to change Conditional Access or Intune.
- Separate named administrative accounts from everyday accounts. Avoid shared accounts for routine operations.
2. Design an architecture the team can operate
For a small team, starting with two dedicated workstations may be simpler than building a complex jump-server infrastructure. If remote desktops are used, protect the originating endpoint too. An administrative VM hosted on an everyday computer inherits trust in that host.
Validate licensing for Conditional Access, Intune, Defender and PIM. A Microsoft 365 subscription does not automatically include every capability; check the subscribed plans and affected users.
| Component | Purpose | Validation |
|---|---|---|
| Dedicated workstation | Supported Windows, Intune management and MDE protection | Controlled provisioning and recovery |
| Administrative identity | Named account reserved for administration | Strong methods and least privilege |
| Conditional Access | Authentication, compliance and approved device | Portals AND PowerShell covered |
| PIM | Temporary role activation | Available approvers and audit records |
| Emergency account | Independent recovery | Test outside the normal access path |
3. Prepare the workstation before restricting other access
Create a dedicated Intune profile and enroll administrative devices. Define configuration settings separately from compliance requirements: assignment alone does not prove compliance.
An ordinary compliant endpoint is not automatically an administrative workstation. Identify which devices are approved for that purpose and protect management of that inventory.
- Enable Secure Boot, BitLocker and virtualization protections compatible with the hardware; test BitLocker recovery.
- Deploy updates, MDE, firewall settings and ASR rules validated in a pilot.
- Remove standing local administrator rights; arrange recovery through Windows LAPS.
- Limit applications and browser extensions to approved tools; pilot application control before broad enforcement.
- Reserve the workstation for administrative destinations and tasks. Use the everyday device for email and general browsing.
- Protect the administrators who can change Intune profiles, deployed applications and Defender exclusions.
4. Require phishing-resistant authentication
Register and test suitable methods before imposing the restriction: FIDO2 passkeys, Windows Hello for Business or certificate-based authentication according to the selected strength and scenario. Prepare an independent backup method and a controlled enrollment process.
Under Entra ID > Conditional Access > Policies, create CA-ADM-Authentication. Target a pilot group containing administrative accounts, select the required resources, then Grant access > Require authentication strength > Phishing-resistant MFA. Start in Report-only.
For accounts reserved exclusively for administration, All resources provides broad coverage to test. Restricting only a portal can leave API access paths uncovered. Directory roles targeting does not cover every role type: explicitly account for custom and administrative-unit-scoped roles.
5. Combine compliance with approved device identity
First create an Intune compliance policy and verify that at least one pilot device meets it. In CA-ADM-CompliantDevice, require the device to be marked as compliant for the same accounts and resources. When combining controls in one policy, choose Require all the selected controls if the requirements must be cumulative.
Add a separate block policy, CA-ADM-ApprovedDevice, targeting those accounts and resources and excluding only devices identified as approved workstations. Microsoft illustrates this pattern with extensionAttribute1. Exclusion from this block policy does not exempt the device from other authentication and compliance policies.
- Assign the marker only after device validation and restrict permissions to modify it.
- Do not use the device name alone as proof of trust.
- Test an unregistered device: its filter properties are null.
- Test a compliant unmarked device, a marked noncompliant device and an everyday workstation.
- Validate browsers and PowerShell clients: device identity must be conveyed to the service.
device.extensionAttribute1 -eq "SAW"6. Replace standing roles with PIM activations
Under ID Governance > Privileged Identity Management > Microsoft Entra roles, inventory assignments before removing anything. Select the minimum role for each job function and create an eligible assignment when continuous access is unnecessary.
Under Roles > Role settings, configure a short duration compatible with the work, justification, notifications and approval for sensitive roles. One hour is an example starting point for a discrete task, not a universal rule. Test activation before removing the corresponding permanent assignment.
Provide multiple approvers available during support hours. Entra roles, Azure roles and service-specific permissions have different scopes: configuring Entra PIM does not automatically cover everything else.
7. Protect activation itself
PIM can require a Conditional Access authentication context during activation. Create the context, associate it with a policy enforcing the desired controls, then select it in the role settings.
Target that policy to eligible users or their group, not only the role they are trying to activate: they do not hold it yet. Retain resource access restrictions after activation as well. A basic PIM MFA requirement may be satisfied by authentication already present in the session; it does not guarantee a fresh challenge at every activation.
Do not equate role expiration with instant termination of every open session. Test service behaviour and plan revocation and incident response separately.
8. Validate with a test matrix
Report-only evaluates without enforcing the restriction. Inspect Success, Failure, User action required and Not applied; the last result is not proof that a control succeeded. Use What If to prepare scenarios, then perform actual sign-ins. A single browser session is insufficient.
Enable one policy at a time for the pilot. Test a fresh session, administrative tools and recovery before expanding the group.
| Scenario | Expected result |
|---|---|
| Approved compliant device, strong method, active role | Operation allowed within the role scope |
| Everyday compliant workstation | Administrative access denied by device restriction |
| Approved device becomes noncompliant | Access denied when compliance is evaluated |
| Method does not meet required strength | Additional authentication or denial |
| Eligible user without an active role | Activation available through intended path; privileged operation denied |
| Emergency account | Recovery available under the tested procedure |
| Graph or Exchange PowerShell | Same protection objective as the portals |
9. Monitor sign-ins and configuration changes
Send Entra logs to Log Analytics if collection is available and authorized. Define retention and cost controls; these queries assume SigninLogs is populated. Replace example accounts with the real inventory. This explicit selection does not automatically discover all administrators.
The first query identifies successful sign-ins with missing or false compliance signals. It is an investigation starting point, not proof of compromise. Correlate device, resource, evaluated policy and intended exceptions.
- Alert on emergency account use and Conditional Access exclusion changes.
- Monitor role assignments, PIM settings and administrative group changes.
- Review device marker changes and who can write that property.
- Correlate MDE alerts with sign-ins and PIM activations.
- Cover noninteractive sign-in logs and application identities with separate monitoring.
let Admins = dynamic(["admin.alex@contoso.com", "admin.sam@contoso.com"]);
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName in~ (Admins)
| where tostring(ResultType) == "0"
| extend DeviceId=tostring(DeviceDetail.deviceId), Compliant=tobool(DeviceDetail.isCompliant)
| where isempty(DeviceId) or isnull(Compliant) or Compliant == false
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, DeviceId, Compliant, ConditionalAccessStatusSigninLogs
| where TimeGenerated > ago(7d)
| mv-expand Policy = ConditionalAccessPolicies
| extend PolicyName=tostring(Policy.displayName), PolicyResult=tostring(Policy.result)
| where PolicyName startswith "CA-ADM-"
| summarize Events=count(), Users=dcount(UserPrincipalName) by PolicyName, PolicyResult
| order by Events desc10. Prepare emergency access and rollback
Retain protected, monitored and tested emergency accounts, with documented exclusions from policies that could prevent recovery. An exclusion does not mean an account should use a weak password or be exempt from every protection.
Before enforcement, export policy configuration and record identifiers, groups and exclusions. If access is blocked, use the tested recovery path to disable only the responsible new restriction, correct targeting and repeat the pilot.
If an administrative workstation is compromised, isolate it, examine its sessions and actions performed by its accounts, then rebuild from a controlled source. Adding the device to an exclusion is not remediation.
A four-stage rollout
Success means administrative operations work from a controlled access path and are denied from other paths. A screenshot showing PIM enabled or a Conditional Access policy created is insufficient: demonstrate both outcomes.
- Prepare: inventory administrators, licensing, workstations, strong methods and recovery.
- Pilot: compliance, authentication, approved devices and PIM activation with a small group.
- Enforce: enable policies individually and document real operations and denial tests.
- Maintain: review privileges, updates, exceptions, alerts and recovery exercises.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →