A local admin access review asks who can administer a laptop or a workstation, on that machine, and why the seat is still there. Cloud IAM reviews do not answer it. A person can have no AWS permission set and still be in the local Administrators group on every engineer laptop, which is enough to read the browser profile, the SSH keys, and whatever the SSO session has cached. SOC 2 access reviews that sample only the IdP roles will miss that population. The campaign has to list devices and the people projected onto them as administrators.
Rutagon builds the collect and the campaign for that population. The grant usually comes from the directory, not from someone walking up to the machine: a Microsoft Entra role, a device setting, or an Intune policy that manages the local group. Microsoft documents the Entra-side assignment in how to manage the local administrators group on Microsoft Entra joined devices. We read those assignments, map them to people, and put a decider on each one. The GRC platform stores the decision. The directory and the device policy are where the seat is actually removed.
What a local admin access review collects
The population is devices that are joined and active, plus the admin seats on each. A seat is a user or a group that lands in the local Administrators group. We do not start from a spreadsheet of "IT people." We start from the policies that write that group.
On Entra-joined Windows devices, several grants stack. The user who joined the device is a local administrator unless that default was turned off. The Microsoft Entra Joined Device Local Administrator role adds more people, and those people become administrators on joined devices. A separate device setting can name additional local administrators. Intune can push a local users and groups policy that inserts a security group into Administrators on a targeted set of devices. Any one of those can be the reason a person is an admin. A review that only exports the Entra role will miss the Intune policy, and a review that only exports Intune will miss the join default.
We store one row per grant path, not one row per person. The same engineer can be an admin because of the role and because of a policy aimed at a device group called Engineering Laptops. Revoking one path leaves the other. The row carries device id, device name, grant path, principal, and the policy or role id. When the principal is a group, we expand the group to users for the campaign and keep the group id on the row, because the removal is usually "take this user out of Workstation Admins," not "edit one laptop."
Nested group access review matters here when Workstation Admins contains another group that contains the company. Expansion shows that. A local admin campaign that displays only the outer group name will be approved in a minute, and every employee remains an administrator on the engineering image.
macOS is a different collect, and we do not pretend the Windows policy export covers it. Where the fleet uses a directory group or an MDM payload to grant the admin group, we ingest that payload's assigned group and run the same campaign shape. Where a machine was granted admin by a one-off local account, the row says local_account and the device owner is the reviewer. The point is the same: a named person decides, and the grant path is visible.
The campaign row and the standing group
The standing pattern we keep finding is a single security group in Administrators on every laptop, with membership that only grows. The group was created so IT could install a driver in 2022. Contractors were added for a week and stayed. The local admin access review makes that group a privileged entitlement, reviewed on the same cadence as cloud admin, with a shorter due date than ordinary SaaS groups.
device_id: dev-1844
platform: entra-joined-windows
grant_path: intune-local-users-and-groups
policy_id: pol-77
principal: group:workstation-admins
member: user:a.lopez
expanded_from: workstation-admins
reviewer: device-owner-manager
decision: pendingThe reviewer is not the person who holds the seat, deciding on their own admin rights. For a shared IT group, the reviewer is the endpoint owner. For a joiner-default seat on a single laptop, the reviewer is that user's manager, because the question is whether this person still needs to administer this one device. Entitlement owner mapping is how we refuse a campaign whose reviewer field is empty. An unowned admin group does not get auto-approved.
Privileged Identity Management can time-box some directory roles that feed this population. Entra PIM access review covers eligible and active assignments for those roles. PIM eligibility is not the same fact as a permanent member of the local admin group pushed by Intune. We show both on the person: eligible for the Entra device-admin role, and also a permanent member of the group the policy projects. Reviewers who clear the PIM assignment and leave the group have cleared the path they were shown and left the path the device uses.
Windows LAPS is adjacent and easy to mix in. LAPS rotates the password of the built-in local administrator account and stores that password in the directory. Rotation is a credential control. It does not list, and does not shrink, the users in the Administrators group. We record whether LAPS is enabled as a separate evidence field on the device. We do not accept "LAPS is on" as a completed local admin access review. The review item is still the person or the group.
Removal that survives the next policy refresh
Revoke has to hit the grant path, or the next policy refresh puts the seat back. Removing a user from the local group by hand on one laptop fails the moment Intune reapplies. The remove we record is a directory change: the user leaves the group named on the row, or the policy stops targeting that device, or the Entra role assignment is removed.
The evidence is the request id from that directory change and a later collect that shows the path gone. The later collect is the following day's ingest, not a screenshot taken while the help desk was on the phone. If the afternoon ingest still shows the member, the item stays open and the grant path column says which policy reintroduced it. That is the same recheck we use on cloud entitlements. A ticket status of "resolved" is not the recheck.
Maintain requires a reason and an end date for anyone who is not in the standing endpoint-operations role. "Developer needs admin for Docker" with no end date is the reason code we reject until a date is entered. The date is stored on the membership, and the expiration job removes it or re-opens a review when the date passes. Permanent maintain is available for the endpoint-operations role, and that decision is what the auditor should see: a small named set, reviewed, with everyone else either dated or gone.
Device scope belongs in the row. An admin grant on a kiosk in a lobby is a different risk from an admin grant on a finance laptop, and both are different from a build agent that is domain-joined and also has a cloud role. We do not fold build agents into this campaign. A machine identity that deploys code is a CI role, reviewed in the privileged access review population for AWS and in the CI role campaign for the pipeline. Stuffing servers into the laptop review hides both.
The GRC platform gets the closed campaign: device, person, grant path, decider, time, and either an end date or a standing reason. Screenshots of the Intune blade go stale the day the policy changes. The export is regenerated from the collect. Security automation is the collect, the expansion, the campaign, and the directory remove. A cloud-only access review can still be complete for cloud, and this population will be absent from it until it is added on purpose.
Personal machines that are not enrolled are out of scope for the policy collect, and we say so in the evidence file. The population statement is "enrolled devices," with the count, the platforms, and the grant paths we were able to read. An evidence file that implies every endpoint in the company was reviewed, when the collect only saw enrolled Windows devices, is the file we will not write. The count of enrolled devices and the count of devices with a non-operations administrator are the two numbers on the cover sheet.
Frequently Asked Questions
Does a cloud IAM access review include local administrators?
Only if you add that population. Identity Center permission sets and Entra directory roles do not list the local Administrators group on a laptop. The local admin campaign is a separate collect from the device directory and the MDM policy that projects groups onto those machines.
Who should approve a local admin seat?
A person who does not hold the seat. Shared IT groups go to the endpoint owner, and a joiner-default admin on one laptop goes to that user's manager. Items with an empty reviewer stay open, and the holder of the admin right is not the sole decider.
If we remove someone on the laptop, is the review complete?
A local edit is overwritten when the Intune policy or the Entra assignment reapplies. The removal we record is the directory change on the grant path, followed by the next ingest showing the path gone. A help-desk ticket marked resolved, with no later collect, stays an open item.
Is LAPS a substitute for this review?
LAPS rotates the built-in local administrator password, which is a credential control on one account. People and groups in the Administrators group are a different list. We can attach LAPS status to the device record, and the campaign item is still the person or the group.
What is a reasonable maintain decision?
Endpoint operations can be a standing named group, reviewed each cycle. Everyone else needs an end date. A maintain reason with no date is returned to the reviewer. The date feeds the removal job so the exception does not become a permanent member of the laptop admin group.
Ask for an access-review diagnostic of who is a local administrator on enrolled devices and which policy puts them there. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.