What does restricting admin privileges for the Essential Eight involve in Microsoft environments?
A customer, contract or regulator that now asks for Essential Eight evidence on privileged access is asking you to show how admin rights are limited, separated and monitored. Your organization owns those controls. An implementation partner can prepare the Entra PIM, LAPS and Credential Guard configuration and the evidence that goes with it, but only an independent assessor or auditor reaches a conclusion on whether the strategy is met. Plan the work with that split in mind from the start.
The size and shape of the work depends on four things. The first is the target maturity level, because the Essential Eight Maturity Model sets different requirements for Levels One to Three, and the ML3 credential protection expectations (Local Security Authority protection, Credential Guard and Remote Credential Guard) are the heaviest. The second is how many privileged roles exist across Entra ID, Azure and Microsoft 365, since each role needs an owner, an eligibility assignment and an approval rule in PIM. The third is whether high-privilege accounts are synchronised from on-premises Active Directory. Microsoft's guidance recommends cloud-only accounts for those roles, so synchronised accounts usually mean a migration decision. The fourth is how many devices need LAPS, since each device needs a unique, rotated local administrator password that can be shown to an assessor.
Before you request a quote, confirm the current role assignments, which admin accounts also hold mail or web licences, whether any service or break glass accounts sit outside PIM, and which devices are not yet covered by LAPS. Ask the partner to state in writing which of these items it will configure, which it will only document, and which evidence the organization must collect itself, such as PIM audit history and access review records. The assessor will test that evidence, so it must come from your own tenant and devices.
How cloud-only accounts, Entra PIM, LAPS and Credential Guard fit together
Cloud-only accounts are identities created and held directly in Microsoft Entra ID rather than synchronized from on-premises Active Directory. Microsoft's guidance recommends them for high-privilege Entra ID, Azure and Microsoft 365 roles, because a compromise of the on-premises directory then cannot silently extend into the cloud administration plane. The account is the anchor for every other control on this page, so it is the first decision to make.
- Separate identities: Keep a dedicated admin account for each person, distinct from the everyday user account used for email and documents.
- Role scope: Assign high-privilege Entra ID, Azure and Microsoft 365 roles only to cloud-only accounts, and document any exceptions.
- Break glass accounts: Hold at least one emergency account with credentials that are long, unique, unpredictable and managed (ISM-1685), stored under dual control and tested on a schedule.
- Sync boundaries: Confirm which roles remain reachable from synchronized identities and whether that is a conscious decision.
- Naming and inventory: Maintain a current list of privileged accounts, their owners and their roles, because assessors will ask for it first.
Check the Entra ID role assignment report against your privileged account inventory and confirm that no synchronized account holds a high-privilege role without a recorded justification.
Privileged accounts must not reach the internet, email or web services unless explicitly authorized, and any authorized access must be strictly limited to what duties require (ISM-1175, ISM-1883). The practical risk is that an administrator's account reads a phishing message or browses a malicious site while holding elevated rights. Microsoft suggests removing Microsoft 365 licenses from privileged accounts, which removes the mailbox and the productivity apps that would otherwise be used for everyday work.
- License removal: Remove Microsoft 365 licenses from admin accounts so they have no mailbox, Teams or Office apps to misuse.
- Exceptions: Record each authorized case where a privileged account needs email or web access, the duty that requires it and the approver.
- Browsing path: Direct administrative browsing to the Privileged Access Workstation rather than the standard desktop, so web use is confined to a hardened device.
- Access reviews: Review the authorized exceptions on a recurring basis, not only at onboarding.
- Verification: Test that a privileged account cannot sign in to Exchange Online or open a web mail session.
Confirm with your legal and HR teams whether removing licenses affects retention, mailbox holds or incident response access, since those obligations often assume a mailbox exists.
Microsoft Entra Privileged Identity Management (PIM) provides time-bound, just-in-time activation of privileged roles. Instead of holding standing rights, an eligible administrator requests activation for a defined period, optionally with approval, justification or multifactor authentication. This addresses ISM-1508 and ISM-1883 and the ML3 expectation that just-in-time administration is used (ISM-1649). It also creates a record of who elevated, when and why.
- Eligibility over permanence: Convert standing high-privilege assignments into eligible assignments wherever the role allows it.
- Activation rules: Decide the maximum activation duration, the approval requirement and the justification required for each role.
- Inactivity and revalidation: Configure access reviews so privileged access is disabled after 45 days of inactivity (ISM-1648) and after 12 months unless revalidated (ISM-1647).
- Alerting: Route activation and approval events to your monitoring platform so elevation is visible in near real time.
- Break glass exclusion: Decide how emergency accounts are handled, because they usually sit outside PIM by design.
Export the PIM audit history for a sample of activations and confirm that each one has a requester, an approver where required, a justification and an end time.
A Privileged Access Workstation (PAW) is a dedicated device used only for administrative tasks. Microsoft describes Secure Admin Workstations managed with Intune and secured with Microsoft Defender for Endpoint, Windows Hello for Business and Entra ID controls, which addresses ISM-1898. The device separates administrative sessions from the browsing and email exposure that the everyday workstation carries, so a compromise there is less likely to reach administrative credentials.
- Dedicated device: Assign each PAW to a named administrator and do not use it for email, general browsing or productivity apps.
- Intune management: Enroll the device, enforce compliance policies and restrict configuration changes to the admin team.
- Defender for Endpoint: Enable endpoint detection and response on the PAW and route alerts to the security operations team.
- Windows Hello for Business: Use hardware-bound credentials for sign-in, which fits the phishing-resistant expectations discussed on the MFA pages.
- Lifecycle: Define how PAWs are built, reimaged, reassigned and retired.
Test that a PAW cannot reach the internet or mail outside the approved administrative paths, and keep the Intune compliance report as evidence.
Local Administrator Password Solution (LAPS) gives each computer a unique local administrator password that rotates automatically, so a single extracted password cannot open every workstation. Credential Guard and Remote Credential Guard, built on virtualization-based security, protect stored credentials from extraction. These support the ML3 credential protection controls: Local Security Authority protection, Credential Guard and Remote Credential Guard enabled (ISM-1861, ISM-1686, ISM-1897). LAPS addresses the requirement that local administrator credentials be unique and managed (ISM-1685).
- Unique passwords: Deploy LAPS so each device has its own local administrator password, rotated on a schedule you set.
- Access to passwords: Limit which roles can read LAPS passwords and log each retrieval.
- Virtualization-based security: Confirm that the hardware and firmware on the estate support the features required for Credential Guard.
- Remote Credential Guard: Decide where remote sessions from administrative devices are permitted and enforce it.
- Compatibility: Identify applications or drivers that break under these protections and document the exceptions.
Collect a report from a sample of devices showing the LAPS policy, the last rotation time and the Credential Guard state, and confirm each value matches the configured baseline.
How a privileged access rollout moves from inventory to assessor evidence
This sequence turns scattered admin accounts and standing permissions into a documented privileged access model, with each phase leaving evidence that an independent assessor can test against the Essential Eight restrict administrative privileges strategy and the ISM controls behind it.
Inventory privileged roles and accounts
Your identity and security team lists every Entra ID, Azure, Microsoft 365 and on-premises role that grants elevated rights, along with each human, break glass, local administrator and service account that holds them. The team records who owns each account, what it is used for, when it last signed in and whether it has standing rights. The step is complete when the inventory is signed off by the control owner and reconciled against directory exports, so the population the assessor samples is known and complete.
Scope which accounts become cloud-only
Using the inventory, the team decides which high-privilege accounts move to cloud-only identities rather than staying synchronized from on-premises Active Directory, as Microsoft's guidance recommends for Entra ID, Azure and Microsoft 365 roles. Each decision is written down with its owner, the dependencies it affects and the break glass accounts kept outside normal sign-in flows. The output is an approved scope list and a change record that the assessor can compare with the original inventory.
Design PIM role settings and approval paths
Administrators configure Microsoft Entra Privileged Identity Management so that eligible roles are activated only when needed, with activation time limits, justification, phishing-resistant authentication on activation and approval where the role warrants it. Designs for each role are reviewed by someone who does not own it. The output is a role settings register showing, for every privileged role, who is eligible, how activation works and what is logged, which supports the just-in-time requirements in ISM-1508 and ISM-1649.
Deploy Privileged Access Workstations and LAPS
Administrators build Privileged Access Workstations managed through Intune, protected by Defender for Endpoint, Windows Hello for Business and Entra ID controls, and they remove Microsoft 365 licenses from privileged accounts so those accounts cannot use email and web services. LAPS is deployed so each computer receives a unique, rotated local administrator password. The output is a device compliance report for the PAW population, a licence removal record and a LAPS coverage check, all of which show the controls in ISM-1175, ISM-1898 and ISM-1685 are in place.
Enable credential protection on ML3 devices
For the ML3 credential protection controls, the team enables Local Security Authority protection, Credential Guard and Remote Credential Guard on the devices in scope, which depends on virtualization-based security being available. Results are checked on a test group before wider rollout, and exceptions are recorded with a compensating control. The output is a device configuration report and an exception register that show ISM-1861, ISM-1686 and ISM-1897 are met for the in-scope population. Organizations targeting ML2 may treat this step as a planned uplift item, so confirm the target level first.
Set access review and disablement rules
The team configures recurring access reviews and disablement rules for privileged access. Accounts inactive for 45 days are disabled under ISM-1648, and privileged access is removed after 12 months unless a named owner revalidates it under ISM-1647. Reviewers confirm or remove each assignment, and disablements are logged. The output is a review schedule, completed review records with reviewer decisions, and a log of disabled accounts that the assessor can sample against the inactivity and revalidation rules.
Collect evidence and hand over to the assessor
The team gathers the evidence set for each control: the signed-off inventory, scope decisions, PIM settings exports, PAW and LAPS reports, credential protection reports, review records and sign-in and activation logs. It maps each item to the ISM control it supports and checks that the evidence covers the period the assessor will test. An independent assessor, not DeployOpen or the implementation team, reviews this package and forms its own conclusions. The output is an indexed evidence pack and a handover note listing known gaps and exceptions.
What must be in place before an assessor reviews privileged access
An assessor testing privileged access looks for one connected story: who holds elevated rights, why they hold them, how those rights are granted and removed, and how credentials on devices are protected. Each item below is a piece of that story that the organization should be able to show before the review begins.
Current inventory of privileged roles
Export the active role assignments from Entra ID, Azure and Microsoft 365 and list every principal holding a high-privilege role, including Global Administrator and the Azure subscription owner and contributor roles. Check that each entry is a cloud-only account where Microsoft's guidance recommends one, and that no privileged role is held by a mailbox-licensed user account. The assessor will compare this list against the PIM records, so any gap between them is the first thing they will question. Confirm the export date and who produced it.
Justification and approval for standing privileges
Every standing privilege that remains active needs a written reason, an accountable approver and a review date. Standing access should be the exception, because the control expects just-in-time administration for most duties. Check each standing assignment against the duty it supports and remove any that cannot be justified. Keep the approval record with the assignment so the assessor can trace the decision without asking staff to reconstruct it.
PIM audit logs kept and reviewable
Entra PIM records activation requests, approvals, role assignments and changes. Confirm that these audit events are sent to the organization's log store and kept for the period the assessor will sample, and that someone can filter them by role and user. Test a sample activation end to end: the request, the justification, the approval and the expiry. An assessor will ask for this trail to prove that elevated access was time-bound and approved, so an empty or unfiltered log is a finding.
LAPS coverage showing unique passwords
Local Administrator Password Solution gives each computer its own local administrator password and rotates it. Produce a coverage report that lists every in-scope device, the LAPS policy it receives, and the time of its last password rotation. Investigate devices that are missing from the report, devices with a shared local administrator password and any with a password that has not rotated. Confirm that the password retrieval permissions are limited to the people who need them, because a readable password store undoes the control.
Credential Guard status on in-scope devices
For ML3 credential protection, the Local Security Authority protection, Credential Guard and Remote Credential Guard need to be enabled on in-scope devices. Report the status of each setting per device, drawing on the management platform or endpoint security reporting. Note the devices that cannot run virtualization-based security, such as older hardware, and record the compensating controls and the decision that accepted them. An assessor will expect either a working device or a documented exception with an owner.
Process for disabling inactive privileged accounts
The control requires privileged access to be disabled after a set period of inactivity and after a set period without revalidation. Write the process that runs these checks, name the owner, and record how the reviews are performed and evidenced. Show one completed cycle with the accounts reviewed, the ones disabled and the approvals for those kept. Confirm that the process also covers break glass, local administrator and service accounts, whose credentials must be long, unique, unpredictable and managed.
Who pays for each part of privileged access work
This table compares each piece of privileged access work by who is paid to do it, whether the cost is one-time or recurring, and what pushes it up or down. Use it to split a quote into internal effort, implementation partner scope and independent assessment. Note that the auditor or assessor fee is separate from implementation, and this page states no prices.
| Component | Who is paid or who does it | One-time or recurring | What drives it |
|---|---|---|---|
| Role and account inventory | Internal identity team, with implementation partner support if scoped | One-time, then refreshed | Number of admin roles, tenants, and shared or legacy accounts |
| Cloud-only account migration | Internal identity team, with partner support for account design | One-time | How many admins currently sign in through synchronised on-premises accounts |
| PIM configuration | Implementation partner or internal Entra ID engineers | One-time, then ongoing tuning | Number of eligible roles, approval chains and activation rules |
| PAW and LAPS deployment | Partner or internal endpoint team, with hardware purchased by the organization | One-time for build, recurring for device lifecycle | Admin headcount, device refresh cycle and Intune policy complexity |
| Credential Guard enablement | Internal endpoint team, sometimes with partner testing | One-time, with testing on each device image | Hardware compatibility, driver support and application testing |
| Licence changes | Organization pays the licence vendor, with internal procurement | Recurring subscription | Licence tier needed for PIM and endpoint tools, and how many admin accounts lose mail or web licences |
| Internal access reviews | Internal control owners and managers | Recurring, typically on a set cycle | Number of privileged roles, review frequency and quality of exported logs |
| Independent assessment | Independent assessor, paid separately from implementation | Recurring, tied to the assessment cycle | Scope of the assessment, evidence readiness and number of systems in scope |
Who owns the controls, who prepares the evidence and who assesses it
Your organization owns the privileged access model. Decisions about who may hold an administrative role, what each role may do, how long elevation lasts and when access is withdrawn are business and risk decisions, and they stay with your security leadership and system owners. Your team also signs off the control design, so the written design reflects what you have actually agreed to run.
- Role decisions: Define which Entra ID, Azure and Microsoft 365 roles are high privilege, and who is eligible for each.
- Approvals: Approve PIM activation requirements such as justification, approver chains and maximum activation windows.
- Access reviews: Run recurring reviews of eligible and active privileged assignments, and remove what is no longer needed.
- Design sign-off: Accept the control design, including the break glass approach and the LAPS password policy, in writing before rollout.
- Operational ownership: Monitor privileged sign-ins and alerts after go-live, since no partner or assessor operates the controls for you.
Before any engagement starts, confirm which named owner signs each decision and where those approvals are recorded.
An implementation partner such as DeployOpen works inside your environment to build the controls you have designed and to prepare the evidence that shows they work. In a scope agreed in writing, the partner might configure PIM, deploy LAPS, set up Privileged Access Workstations, enable Credential Guard and Remote Credential Guard, and organize the evidence into packs. The partner does not decide the control design and does not issue any report, attestation or certificate.
- Configuration: Set up PIM role settings, cloud-only admin accounts, LAPS policy and Credential Guard in your tenant or devices.
- Privileged workstations: Build and harden Privileged Access Workstations, managed through Intune and protected with the Microsoft security controls your team selects.
- Evidence packs: Export PIM audit history, LAPS configuration, group membership reports and device compliance results, and label each against the relevant control.
- Gap notes: Record where a setting does not match the agreed design, so your team can decide how to close it.
- Handover: Document the configuration and the runbooks your staff need to operate the controls afterward.
Ask the partner to state in the statement of work that it prepares evidence and does not issue conclusions.
The independent assessor tests whether the privileged access controls are implemented and effective against the Essential Eight maturity model and the ISM controls it references. The assessor samples your evidence, may test settings directly, and forms its own conclusion about the maturity level reached. Only the assessor's conclusion carries independent weight, which is why the assessor must not be the same party that configured the systems.
- Independence: Choose an assessor that did not design or build the controls being tested.
- Testing: Verify that PIM requires justification and approval, that eligible roles are reviewed, and that LAPS passwords are unique and rotated.
- Sampling: Select accounts, devices and activation records to test, rather than accepting a single screenshot.
- Conclusion: Report findings and the maturity conclusion in the assessor's own document.
- Scope limits: Test only what is in the agreed assessment scope, and state any control it could not verify.
Before engaging an assessor, confirm its qualifications for Essential Eight work and what deliverable it will issue.
What to check before hiring help for privileged access
Privileged access work touches identity, endpoints and evidence at once, so a partner needs to be checked on all three before any work starts. The cards below cover the questions that separate a partner who can deliver PIM and LAPS controls from one who only describes them. DeployOpen works on fixed-scope engagements with scope and deliverables agreed in writing before work begins.
Confirm Entra PIM and LAPS experience
Ask for named examples of Entra PIM role settings, approval workflows and access reviews configured in a live tenant, and for LAPS deployments on Windows endpoints managed by Intune or Group Policy. Ask which Microsoft Learn guidance the partner follows for cloud-only admin accounts and how it handles high-privilege roles that were previously synchronised from on-premises Active Directory. Vague answers about "identity projects" are a signal to keep looking.
Require a written, fixed scope
A privileged access engagement should list the tenant, subscriptions, device groups, admin roles and PIM policies in scope, along with the deliverables and acceptance criteria for each. Ask what is excluded, such as break glass account design, Privileged Access Workstation hardware or Credential Guard testing on legacy devices. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote follows from that document.
Ask how evidence is prepared
Ask the partner to show the evidence it will prepare for each control, such as PIM activation logs, role assignment exports, LAPS password rotation records and Credential Guard status reports. Confirm which evidence is generated automatically and which requires a documented procedure. The partner prepares this evidence, but the independent assessor decides whether it is sufficient, so ask whether the partner has walked an assessor through similar material.
Check for self-assessment conflicts
A partner that configures privileged access should not also be the party that certifies it meets the Essential Eight maturity level. Ask who will review the configuration, who signs off the assessment and whether the partner will stay out of that review. Only an independent auditor or assessor issues assessment outcomes, so an implementation partner that presents its own work as the verdict is a warning sign.
Confirm who keeps the runbooks
After handover, someone must own the PIM role settings, LAPS policies, admin account inventory and the procedures for reviewing privileged access every 45 days of inactivity and every 12 months. Ask the partner to deliver configuration documentation, runbooks and a list of the named owners inside your organization. Ask whether support is covered by a separate retainer and what the handover acceptance test looks like.
Questions buyers ask about Essential Eight privileged access
Does Entra PIM alone satisfy the Essential Eight restrict administrative privileges control?
No. Entra PIM provides time-bound, just-in-time activation of privileged Entra ID, Azure and Microsoft 365 roles, which covers part of what the ISM expects under ISM-1508 and ISM-1883. The control also requires cloud-only high-privilege accounts, removal of email and web access from admin accounts, separation through privileged access workstations, unique local administrator credentials and credential protection. Your organization owns the policy and its operation, and an assessor will test the whole set. Treat PIM as one component of the control, not the control itself.
Can we implement Essential Eight privileged access ourselves?
Often yes, if your team already runs Entra ID, Intune and Defender and has someone accountable for identity. The work is mostly configuration, documentation and testing, and it touches tenant-wide roles, so mistakes can lock out administrators. Teams that lack Entra or endpoint management experience, or that must produce evidence for an assessment on a fixed date, often bring in an implementation partner for the build. DeployOpen plans and implements these controls inside your own tenant and infrastructure under a fixed-scope written agreement, but the policies, role assignments and sign-off remain yours.
How much effort falls on our own team?
Effort depends on how many privileged accounts you have, how many roles are standing assignments today, whether admins currently use mailboxes or browse from their daily device, and how mature your Intune estate is. Your team typically owns role inventory, approval decisions for who may activate which role, exception handling, and periodic access reviews. Ask any provider to split their quote into design, build, testing and handover, and to state which tasks require your staff and for how long. Recurring work such as quarterly access reviews and inactivity cleanup continues after the project ends.
What evidence will an assessor request for privileged access?
Assessors usually ask for proof that the control operates, not only that it was configured. Expect a list of privileged roles and holders, PIM activation and approval logs, evidence that cloud-only accounts are used for high-privilege roles, configuration exports showing licences removed from admin accounts, LAPS settings with password rotation records, and Credential Guard status on sampled devices. They will also look at access review records and disabled accounts for the 45-day inactivity and 12-month revalidation rules. Confirm the exact evidence expectations with your assessor before the engagement starts.
How does this relate to ML2 and ML3 logging?
Privileged activity has to be recorded in a way that can be reviewed. At ML2, logs of privileged role use and changes should be collected centrally and retained so that they can be reviewed later. At ML3, the expectations for detecting and investigating misuse become stricter, and credential protection is also required. Sign-in and PIM audit events, endpoint events and LAPS retrieval events all matter here. Confirm the retention period, the review frequency and the alerting you must meet with your target maturity level and your assessor, because those details come from your own requirements and the ASD maturity model.
What changes if we run hybrid Active Directory?
Hybrid environments need more care because on-premises accounts that sync to Entra ID can carry privileged roles into the cloud. Microsoft's guidance recommends cloud-only accounts for high-privilege Entra ID, Azure and Microsoft 365 roles, so you will need to create and govern a separate admin identity set and remove synchronized accounts from those roles. Domain admin credentials, LAPS for local passwords and tiered administration also need to be planned together. Expect more discovery work and more change control, and confirm the design with your identity team before changing any production role.
Does DeployOpen certify us against the Essential Eight?
No. The Essential Eight is a set of mitigation strategies rather than a certification scheme, and there is no ASD certificate. DeployOpen prepares systems, configurations and evidence for your assessment, but does not issue audit reports, attestations or certifications. Maturity is judged by an independent assessor against the ASD maturity model, and your organization owns its controls. Ask any provider for a written statement of exactly what they deliver and what remains with your assessor.
How DeployOpen works on this
DeployOpen plans, implements and documents privileged access controls for the Essential Eight inside your own Microsoft tenant and infrastructure, so the admin model is shaped to your environment. We prepare systems and evidence for your assessor, while your organization owns the controls and the independent assessor issues any conclusion about maturity.
How we scope
- Engagements are fixed-scope, with the tenants, admin roles, device groups and maturity level agreed in writing before work starts.
- We inventory which Entra ID, Azure and Microsoft 365 roles hold standing privilege and which accounts today receive mail and web access.
- The written scope names who owns each decision, including break glass accounts, PAW hardware and the PIM approval workflow.
How we build
- We configure cloud-only admin accounts and PIM eligible assignments with time-bound activation, approval and justification settings.
- We deploy LAPS for unique, rotated local administrator passwords and check Credential Guard and Remote Credential Guard status on in-scope devices.
- We test each control against the agreed scope, including attempts to use privileged accounts for email or web browsing, and record the results.
How we hand over
- Deliverables include configuration exports, PIM role settings, sign-in and activation logs, and a written test record mapped to each ISM control in scope.
- Runbooks cover break glass procedures, access reviews, PAW patching and steps to revoke inactive privileged accounts.
- We walk your team and your assessor through the evidence, so your staff can reproduce the checks without DeployOpen involved.
How we support
- Ongoing support, upgrades and continuous testing of the admin model are available as a retainer, agreed separately from the initial scope.
- Retainer work can cover periodic access reviews, role changes and re-running the test record when Microsoft features or your tenant change.
- Ask any quote to separate one-time build effort from recurring support, so you can see what the ongoing commitment costs.
