{"id":34411,"date":"2026-06-09T22:18:11","date_gmt":"2026-06-09T22:18:11","guid":{"rendered":"https:\/\/www.adminbyrequest.com\/en\/?p=34411"},"modified":"2026-06-10T01:07:34","modified_gmt":"2026-06-10T01:07:34","slug":"passing-cyber-essentials-plus-with-run-as-admin-how-we-handle-account-separation","status":"publish","type":"post","link":"https:\/\/www.adminbyrequest.com\/en\/blogs\/passing-cyber-essentials-plus-with-run-as-admin-how-we-handle-account-separation","title":{"rendered":"Passing Cyber Essentials Plus With Run As Admin: How We Handle Account Separation"},"content":{"rendered":"\n

If you’re working toward the UK NCSC’s Cyber Essentials Plus<\/a> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Admin By Request EPM<\/a> 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.<\/p>\n\n\n\n

What Cyber Essentials Plus Asks For<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Why Our Run As Admin Mode Counts as Second Account Elevation<\/h2>\n\n\n\n

Admin By Request EPM’s Run As Admin mode<\/a> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Prism Infosec, a CREST-certified UK security company, confirmed this in their independent penetration test<\/a>, 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The Configuration That Passes<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Run As Admin mode needs to be the elevation mode<\/strong>, 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.<\/p>\n\n\n\n

Each elevation request needs a written reason and explicit approval<\/strong> 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.<\/p>\n\n\n\n

MFA needs to happen before the elevation is granted.<\/strong> Admin By Request EPM supports Entra ID, Office 365, and SAML-based MFA, so this slots into whatever identity provider you’re already using.<\/p>\n\n\n\n

A Note on Admin Session Mode and Support Assist<\/h2>\n\n\n\n

Admin Session mode<\/a> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Where MFA Account Separation Fits In<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

A few practical notes on the feature:<\/p>\n\n\n\n