If you’re working toward the UK NCSC’s Cyber Essentials Plus certification, account separation tends to be one of the trickier requirements to get right. The rule itself is simple enough: administrative duties have to be performed using a different account from the one used for everyday work like email and web browsing.
The complication shows up at the configuration layer, since how privilege elevation actually delivers account separation isn’t always obvious to assessors or to the IT teams setting things up.
Admin By Request EPM does pass Cyber Essentials Plus when configured correctly, and we have both an independent penetration test from a CREST-certified UK assessor and our own CE+ certification to back that up. This post walks through why it passes, what the right configuration looks like, and where the MFA Account Separation feature fits in for organizations that need or want it.
What Cyber Essentials Plus Asks For
The CE+ scheme requires that administrative actions are performed using a separate account from standard user activity. The reasoning is straightforward: if your daily-use account gets compromised through a phishing email or a malicious browser plugin, the attacker shouldn’t automatically inherit administrative rights over your systems. Keeping admin work on a different account contains the blast radius when something goes wrong.
Multi-factor authentication on all administrator accounts is also required. So in practical terms, an organization needs to demonstrate two things to an assessor: admin actions are carried out via a non-daily-driver account, and the account performing those actions is protected by MFA.
It’s also worth understanding what the standard was actually designed around. CE+ was written with native OS setups in mind, on the assumption that no EPM solution would be in place. The baseline approach it describes is straightforward: give users one non-admin account for daily work, and one full admin account for administrative tasks. That second account can even be a shared local admin account. It’s compliant by the letter of the standard, but it also means handing out unrestricted admin access, which creates exactly the kind of security exposure that EPM exists to prevent.
There’s also no such thing as a “CE+ certified product.” There’s no approved list. What matters is whether your configuration, whatever tools you’re using, passes the hands-on technical assessment. A sophisticated firewall with a permissive ruleset won’t pass. The same principle applies to privilege elevation: the tool doesn’t confer compliance, the configuration does.
Why Our Run As Admin Mode Counts as Second Account Elevation
Admin By Request EPM’s Run As Admin mode is purpose-built for compliance scenarios like this one. When a user right-clicks an application and selects Run As Admin, the application itself is elevated while the user’s logged-in session stays in its standard, non-privileged context. Only the specific process they requested gets elevated rights, and only for as long as it’s running.
What matters for CE+ is how that elevation happens under the hood. The elevated process is initiated by the Local System account, not by the user’s account with extra privileges temporarily attached.
Prism Infosec, a CREST-certified UK security company, confirmed this in their independent penetration test, noting that elevations are not initiated in the user’s context but rather by the Local System account, which then initiates the elevated process for the user’s context. That assessment covered both Windows and Mac endpoints.
That’s textbook second-account elevation, with two distinct security principals involved: the user, and the system account that performs the privileged work on their behalf. In effect, Admin By Request EPM acts as the second account, performing the privileged work on the user’s behalf without ever granting elevated rights to the user’s own account.
The Configuration That Passes
Meeting CE+ requirements with Admin By Request EPM comes down to three things being in place: Run As Admin mode only, with reasoning and manual approval required, with MFA before elevation actually happens.
Run As Admin mode needs to be the elevation mode, rather than Admin Session. Admin Session mode is excellent for developers and power users who need flexibility, since it gives them a time-limited window of system-wide elevation across multiple processes. But it doesn’t fit account separation as cleanly, because the user’s context is operating with elevated privileges for that period. Run As Admin mode keeps elevation tightly scoped to individual processes.
Each elevation request needs a written reason and explicit approval from an IT team member, processed through the portal, the mobile app, or one of the integrated channels like Teams, Slack, ServiceNow, or Jira. This creates the audit trail assessors look for and ensures every privileged action has a documented justification.
MFA needs to happen before the elevation is granted. Admin By Request EPM supports Entra ID, Office 365, and SAML-based MFA, so this slots into whatever identity provider you’re already using.
A Note on Admin Session Mode and Support Assist
Admin Session mode isn’t excluded from every CE+ compliance path. When used in combination with our Support Assist feature, an Admin Session can be run under a different account from the one the user is currently logged in with. In that scenario, the separation between accounts is maintained through the Support Assist mechanism rather than the Local System account, and the secondary account involved is also non-privileged, so both accounts in the workflow are non-admin accounts.
For most organizations going through CE+ assessment, Run As Admin mode is the simpler and more direct path. But it’s worth knowing that Admin Session mode has a compliant configuration too, if your specific setup calls for it.
Where MFA Account Separation Fits In
The MFA Account Separation feature was built for a specific situation: customers who already have two separate accounts per user (a standard one and a dedicated admin one) and want to keep that structure for their own reasons.
Some organizations have built their internal processes around dual-account setups over the years and don’t want to unwind them. Some auditors prefer to see two distinct named accounts in the directory, particularly when applying the CE+ rules in a more literal way.
For those customers, MFA Account Separation lets the MFA step be performed by the secondary account rather than the primary one. The user requests elevation from their daily account, but the MFA challenge that approves it is satisfied via their separate admin account through SSO. Two distinct accounts are involved in the workflow, and the audit trail shows it clearly.
A few practical notes on the feature:
- For UK customers, MFA Account Separation is enabled by default. Non-UK customers need to ask their account manager to switch it on for their tenant.
- Endpoints need to be running Windows agent v8.5.1 or later to access the setting.
- The recommended deployment pattern is to downgrade the existing admin or “adm” account to non-privileged status, and let Admin By Request EPM provide the actual privilege elevation, blocking, auditing, and malware protection through a sub-setting configured for that account.
It’s worth being clear about what the feature does and doesn’t do, since this gets confused frequently. The MFA Account Separation feature on its own doesn’t perform the elevation; the elevation still happens through Run As Admin mode and the Local System mechanism described earlier. What the feature adds is the ability to route the MFA approval through a separate user account, which is useful when auditors specifically want to see two named accounts in the workflow.
In this configuration, both accounts are non-privileged. That’s a considerably more secure posture than the CE+ baseline, which permits organizations to satisfy the standard by issuing full, unrestricted local admin accounts as the “separate” privileged account, and even allows those to be shared between users.
This same setup also supports the access control requirements in DORA Article 5 and NIS2 Article 21, both of which call for least privilege enforcement and auditable access to critical systems. For organizations operating across the UK and EU, one configuration covers all three.
Getting Started
The easiest way to see how this works in practice is to deploy Admin By Request EPM to a small test group, configure Run As Admin mode with reasoning and approval, and turn on MFA elevation. You can do all of that on our free plan, which supports up to 25 endpoints with no time limit and no feature restrictions.
The full Cyber Essentials Plus policy statement and the pen test confirmation are available in our Trust Center and Documentation Center if you want to review them ahead of an assessment. If your environment is larger or you want to talk through your specific requirements, book a demo and we’ll walk through the configuration with you.
