Security frameworks and local administrator rights

For security officers, auditors and tenant admins. Not legal or audit advice: verify every point against the current version of the framework and with your assessor.

AdminExplorer helps you implement least privilege on Windows endpoints: users work as standard users, standing membership of the local Administrators group is removed and kept removed, and the programs that really need administrator rights are elevated one at a time, under your policy, with an audit record for every attempt.

AdminExplorer does not by itself make an organisation compliant with any framework. Every framework below also asks for processes, account management, reviews and controls that are outside AdminExplorer (for example multi-factor authentication for administrators, separate admin accounts for IT staff, patching and malware protection). This page shows where AdminExplorer helps and where it does not.

The features named here are documented in the guides and the reference. Unless marked otherwise they are available in the current client and portal; see Release notes for what is released.

CIS Critical Security Controls

Source: CIS Critical Security Controls (the current release is v8.1) and the safeguard wording in the CIS Controls Assessment Specification for Control 2, Control 5 and Control 8.

Safeguard 5.4, Restrict Administrator Privileges to Dedicated Administrator Accounts (Control 5, Account Management). Administrator privileges on enterprise assets belong only to dedicated administrator accounts; everyday work such as browsing, email and office programs is done from a standard, non-privileged account.

How AdminExplorer supports it:

• Local administrator removal and protection removes users from the local Administrators group (and, if you choose, other privileged local groups) and removes them again if they are added back. Start in Report mode to see who is a member, then switch to Enforce. Allowed members (for example your own admin groups or Entra roles) stay.
• How AdminExplorer elevates: users who no longer have administrator rights start the programs they need elevated per program, from your approved list or rules, without becoming administrators.
• The Emergency admin account (Enterprise) gives a break-glass local administrator that is disabled except in a usage window you open from the portal.

Related safeguards where AdminExplorer contributes data:

• 8.2 Collect Audit Logs and 8.5 Collect Detailed Audit Logs: every elevation attempt is written to the Windows Application log and, on enrolled devices, to the portal with device, user, file, hash, decision, reason, approver and duration (Audit and reports).
• 8.10 Retain Audit Logs (at least 90 days): the portal keeps audit records for 400 days on paid plans and 30 days on the Free plan (Licenses, seats and usage), so the Free plan alone does not meet 8.10; export or forward the records if you need them longer.
• 2.1 Establish and Maintain a Software Inventory: Installed software tracking reports what is installed from Add/Remove Programs and links changes to elevations. It is input to an inventory, not a complete one (no license counts or business purpose).

Not covered: 2.5 Allowlist Authorized Software, 2.6 and 2.7. AdminExplorer decides which programs may run with administrator rights; it does not decide which programs may run at all. Use an application control product (for example App Control for Business or AppLocker) for those safeguards.

ASD Essential Eight: Restrict administrative privileges

Source: Essential Eight maturity model and Restricting administrative privileges, Australian Signals Directorate (ASD).

The mitigation strategy has three maturity levels. In general terms, Maturity Level One asks that requests for privileged access are validated, that privileged users have dedicated privileged accounts used only for privileged duties, and that privileged accounts are kept away from the internet, email and web services and from unprivileged environments. Higher levels add requirements such as disabling unused privileged access, central logging of privileged access events and, at the highest level, just-in-time administration. ASD also states that temporarily giving administrative privileges to user accounts, or placing standard user accounts in groups with administrative privileges, does not restrict administrative privileges.

How AdminExplorer supports it:

• Local administrator removal and protection takes standard user accounts out of the local Administrators group and keeps them out, which addresses the “standard users in admin groups” pattern ASD names.
• Users are not given an administrator account. AdminExplorer elevates individual approved programs for them (How AdminExplorer elevates). Whether per-program elevation for standard users is acceptable at your target maturity level is a question for your assessor: agree it before you rely on it. Using AdminExplorer does not by itself achieve any Essential Eight maturity level.
• With Manual approval (Enterprise), an approver validates each on-demand request, and the decision is recorded.
• The audit records and the device event log give a record of privileged program starts that you can send to your central logging (Audit and reports, Event ids and reason codes).

Not covered: the dedicated privileged accounts of your administrators, their separation from internet and email, privileged operating environments, jump servers and Credential Guard. Those are account and platform controls outside AdminExplorer.

UK Cyber Essentials: User Access Control

Source: Cyber Essentials: Requirements for IT Infrastructure v3.3 (NCSC, April 2026), section 4, User Access Control.

User accounts must be given only to authorised individuals and give only the access the role needs. Among other things, the organisation must use separate accounts for administrative activities (no email or web browsing with them), remove or disable special access privileges when they are no longer needed, and use multi-factor authentication where available. The document explains that local administrators are administrative accounts too, and that malware runs with the privileges of the signed-in user.

How AdminExplorer supports it:

• Local administrator removal and protection removes administrative rights from everyday user accounts on Windows devices and shows, per device, who is still a member of a protected group, with exceptions that expire.
• Users do their daily work as standard users and elevate only approved programs (How AdminExplorer elevates).
• Portal administrators sign in with Microsoft Entra sign-in, where your Conditional Access policies (for example MFA) apply.

Not covered: the account creation and approval process, MFA for your cloud services, and the separate admin accounts of your IT staff. Cyber Essentials also lists application allow listing as one option for malware protection; AdminExplorer is not an allow-listing product.

NIS2 Directive: Article 21

Source: Directive (EU) 2022/2555 (NIS2), Article 21; Commission Implementing Regulation (EU) 2024/2690; ENISA NIS2 Technical Implementation Guidance (June 2025, version 1.0).

Article 21 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risks. Article 21(2) lists the areas these measures must cover, among them, in point (i), human resources security, access control policies and asset management. NIS2 is high level: Article 21 does not mention local administrator rights. How you meet it is set by your national law that transposes the directive and by your own risk assessment.

For certain digital-sector entities (for example some digital infrastructure, ICT service management and digital providers) the Implementing Regulation 2024/2690 adds detailed requirements. Its point 11.3 covers privileged accounts and system administration accounts: policies for managing them, specific accounts for administration, and restricting administration privileges to the highest extent possible. ENISA’s technical implementation guidance (June 2025, version 1.0) for that point suggests, for example, granting privileged access only for the time needed and logging all privileged access.

How AdminExplorer supports an access control policy under Article 21(2)(i):

• Removes standing local administrator rights and keeps them removed (Local administrator removal and protection).
• Grants administrator rights per program, by policy, with optional approval and an audit record of who, what, when and why (How AdminExplorer elevates, Audit and reports).
• Can limit how long an elevated program may run (Time-limited elevation). Not yet released: needs client 2.0.68, which is not in the release notes yet.
• Provides a break-glass administrator whose use is revealed, audited and followed by a password rotation (Emergency admin account, Enterprise).

Microsoft guidance on least privilege

Source: Implementing Least-Privilege Administrative Models and User Account Control, Microsoft Learn.

Microsoft’s guidance is to grant the least privilege needed for a task. It notes that in many environments users are members of the local Administrators group on their own computers, and that this is an elevated risk to the workstation even with User Account Control on; organisations should consider carefully whether users need administrative rights at all. User Account Control lets users sign in with a standard user account and run only specific programs with administrator rights.

How AdminExplorer supports it: users stay standard users (Local administrator removal and protection), and the programs that need administrator rights are elevated per program by your policy instead of by a UAC prompt for an administrator password (How AdminExplorer elevates). The Hybrid default preset keeps Domain Admins in the local Administrators group, as the Microsoft page advises.

Control, feature and evidence

Control	AdminExplorer feature	Evidence
CIS 5.4; Cyber Essentials, User Access Control; Essential Eight, standard users not in admin groups; NIS2 Article 21(2)(i)	Local administrator removal and protection	Local admins page and history; audit kind localAdminRemoval; device events 1030 (removed), 2030 (not removed), 2032 (repeat offender), 3030 (removal failed), 3031 (lock-out guard)
CIS 5.4; Microsoft least privilege	Per-program elevation for standard users (pre-approved and on demand)	Audit records with user, file, SHA-256, publisher, decision, matched entry and duration; device events 1009 (pre-approved start), 1010 (on-demand start), 1012 (ended), 2004 (denied)
Essential Eight, validation of privileged access requests; NIS2 point 11.3 with ENISA guidance (approval records)	Manual approval (Enterprise); offline PIN (Enterprise)	Approvals history with approver and comment; audit records with approval mode and approver; device events 1013 (pending), 2008 (expired), 2009 (rejected)
CIS 8.2, 8.5; Essential Eight, logging of privileged access	Audit of every elevation attempt	Portal Audit with CSV export; Windows Application log, source AdminExplorer (Event ids and reason codes)
CIS 8.10	Audit retention	400 days on paid plans; 30 days on the Free plan
CIS 2.1	Installed software tracking	Software inventory and change feed; device event 1022
NIS2 point 11.3 with ENISA guidance (time-bound privileged access)	Time-limited elevation (not yet released, client 2.0.68)	Audit columns Time limit and Ended; device events 1070 to 1073, 2070, 2071
Break-glass administration (CIS 5.4; NIS2 point 11.3)	Emergency admin account (Enterprise)	Audit kind emergencyAccount (reveal with reason, enable, first sign-in, disable, rotation); Emergency account page with CSV export

Approvals in Microsoft Teams are planned and not released yet; today approvers get a mail and decide under Approvals in the portal (Release notes).

Not legal or audit advice. Framework texts change: verify every control against the current version of the framework before you rely on this mapping.