Restrict administrative privileges maturity level 1 requirements

What Essential Eight ML1 privilege restriction asks you to prove

To reach Maturity Level One for restricting administrative privileges, you must show that every privileged access request is validated when first made, that privileged people have a dedicated privileged account used only for privileged duties, and that those accounts cannot browse the internet, send or read email, or use web services unless that access has been explicitly authorised and kept to what the duty needs. You also need to show separate privileged and unprivileged operating environments, with no cross-logon between them except for local administrator accounts. The requirement is delivered through the Information Security Manual, where seven controls are tagged ML1 in ASD's Essential Eight baseline profile: ISM-1507, ISM-1175, ISM-1883, ISM-0445, ISM-1380, ISM-1688 and ISM-1689. Confirm the current wording of each against the ISM OSCAL catalog for your release before you map them to your own control set. Note that the Essential Eight is a set of mitigations, not a certification scheme, so there is no ASD certificate to obtain. An assessor evaluates whether each strategy is implemented and effective against the maturity model, and your evidence is what makes that judgement possible.

The risk these controls address is ordinary and persistent: an administrator signs in to a privileged account to check a mailbox or open a web page, and a phishing link or malicious download then runs with administrative rights. Attackers rely on exactly this habit, so the control is about separating the act of administering from the act of working on the open internet. The difficulty is rarely the technology. Shared administrator accounts make it impossible to say who did what, and privileged rights accumulate over years as people change roles and nobody removes the old grants. Before an assessment, ask your team to produce a list of every account holding administrative rights, the approval record behind each one, and the named person who uses it. Any account without a clear owner or approval is the first gap to close.

A practical starting point is to test the boundary rather than trust the policy. Pick a sample of privileged accounts and attempt, under supervision, to reach a website or mailbox from them, then check that the attempt is blocked or logged. Confirm that a standard user session cannot log on to a privileged workstation or server, and that the exceptions are local administrator accounts only. Keep the results with the approval tickets, role assignments and environment configuration, because an assessor will ask to see the evidence of a control working, not a description of intent. Decide early who owns each piece of that evidence, since the organization owns the control even when an implementation partner prepares the systems and documentation.

Which accounts, systems and teams fall under ML1 privilege controls

ML1 privilege controls apply wherever someone can change security settings, install software or act with rights beyond a standard user. The scope decisions below determine how much inventory, approval and separation work an organization takes on, so settle them before writing procedures.

Privileged human users

Start with every person who holds rights beyond a standard user, including staff with domain or tenant roles, database owners and network engineers. Include contractors and vendor staff who sign in with their own identities. For ML1, the control that matters most is that each privileged human has a dedicated privileged account used only for privileged duties, so the inventory should list accounts, not people. Check for shared administrator logons, which the control does not allow.

Endpoint administrator roles

Local administrator rights on workstations and laptops are a common gap. Identify every group or account that can elevate on endpoints, including help desk roles and any software that runs with local admin rights. Decide early whether local administrator accounts sit inside the environment separation rule, because that choice changes how users are configured and how often they switch sessions. Document the decision and apply it consistently.

Server and infrastructure administrators

Server administration covers domain controllers, hypervisors, backup servers, network devices and jump hosts. These systems usually have the widest reach, so their admin groups should be listed separately from workstation groups. Confirm which accounts can reach these hosts from the internet, email or web services, since ML1 restricts privileged accounts from those paths unless explicitly authorized. Record any exceptions with a named owner.

Cloud tenant and SaaS administrators

Global administrators, subscription owners, identity providers and SaaS tenant admins often sit outside the data center and are easy to overlook. Export role assignments from each tenant and compare them with the on-premises list. Privileged roles granted to service principals or integrations belong in scope too. Ask each platform owner which roles can be assigned without a second approver.

Approving teams and request owners

ML1 requires that requests for privileged access are validated when first made, so the approvers must be defined. Name the team that validates requests, the system owners who confirm need, and the security function that reviews them. Separating the requester from the approver reduces the chance of self-approval. Check that approvers have the system knowledge to judge whether a request is necessary and limited.

Third parties with admin rights

Managed service providers, software vendors and outsourced support staff often hold administrator rights on systems the organization owns. Their accounts must still meet the dedicated account, validation and access restriction requirements. Confirm which vendor accounts are named, which are shared, and how they are disabled when a contract ends. Vendor access should appear in the same register as internal privileged accounts.

How to implement validated access and dedicated privileged accounts

This sequence turns informal administrator access into a register of approved privileges, dedicated accounts and enforced logon boundaries that an assessor can test against the Maturity Level One controls. Each step produces an artefact that the next step depends on.

Inventory all privileged access today
Start by listing every account, group, role and local administrator right that can change systems, data or security settings. Include directory roles, cloud subscription owners, hypervisor and network device administrators, database owners, and local administrator accounts on endpoints and servers. The system owner and the identity team should confirm the list together, because accounts often exist that nobody remembers creating. The output is a draft privileged access register with the holder, the system, the privilege and the justification for each entry. You know this step is done when a sample of systems produces no privileged access that is missing from the register.
Define the validated request and approval workflow
Write a procedure that says how a person requests privileged access, who validates the need, who approves it, and what evidence is kept. Validation should happen when access is first requested, not only when it is renewed, so the request should name the duty, the systems and the period. Decide which tool holds the request, for example a ticketing or identity governance workflow, and confirm that its records can be exported for assessment. The output is an approved procedure and a request template. You know this step is done when a test request runs end to end and leaves a retrievable approval record.
Validate and approve the existing register
Run every entry in the inventory through the new workflow. Remove access that cannot be justified, and record the validation decision and approver against each remaining entry. Directory tools that support access certification, such as midPoint campaigns with designated reviewers, can help record these decisions consistently. The output is an approved access register in which every privileged entry has a validation record. You know this step is done when no privileged entry exists without a dated approval.
Create dedicated privileged accounts
For each privileged human user, create a separate privileged account and use it only for privileged duties. The daily account stays for email, browsing and ordinary work. Naming conventions help assessors see the separation, for example a prefix or suffix on the privileged identity, but the rule that matters is that the privileged account is used only for privileged work. Document where each account is created and who controls its credentials. The output is a list of dedicated accounts mapped to their daily accounts in the register. You know this step is done when logs show each privileged account used only for administrative tasks.
Block internet, email and web access for privileged accounts
Configure the directory and endpoint policies so privileged accounts cannot browse the web, read email or use web services unless an authorisation is recorded. Where a privileged task genuinely needs one of these services, document the authorisation and limit it to what the duty requires. Test the restriction by attempting a browser session, a mail client sign-in and a web service login from a privileged account, and capture the denied results. The output is a written policy and a set of test results showing the refusals. You know this step is done when the tests fail as designed and the exceptions list is short and approved.
Separate privileged and unprivileged operating environments
Provide privileged users with a privileged operating environment, such as a dedicated administrative workstation or a separate virtual machine, that unprivileged accounts cannot log on to. Configure the systems so that privileged accounts other than local administrator accounts cannot log on to unprivileged environments. The design should be recorded so that the boundary can be explained to an assessor. The output is an environment design and a logon restriction. You know this step is done when a test shows an unprivileged account refused at the privileged environment and a privileged account refused at a standard workstation.
Test the logon restrictions and record the evidence
Before declaring Maturity Level One coverage, run a repeatable test of each control: validated request, dedicated account use, internet and email restriction, and environment separation. Keep dated screenshots, configuration exports and log extracts for each test, and link them to the control identifiers in your governance tool. Ask an independent assessor whether they would accept the evidence format before the formal assessment. The output is a test pack with a result for each control. You know this step is done when every test has a dated result and an owner who can explain it.

How an assessor tests validated privileged access requests

A documented policy says privileged access must be validated before it is granted. An operating control is the record that shows it happened, for each grant, at the time it was first requested. Assessors treat the policy as the design and the request tickets, validation notes and approval records as the proof. An organization can have a well-written privileged access procedure and still fail this test if its administrators received rights through a shared group, a standing role assigned during a project and never reviewed, or an email from a manager that nobody filed. The first question an assessor asks is therefore not whether the policy exists but whether the process runs the same way every time.

In practice the assessor draws a sample of privileged grants from the directory or identity provider, not from the request system, so that unrecorded grants are not missed. For each sampled grant, the assessor traces the account or group membership back to a request, then checks who validated the need, against what criteria, and who approved it. The key comparison is timing: the validation must precede the first time the access was granted, not a later clean-up exercise. Assessors commonly look at group membership change logs or directory audit events to confirm the grant date. Organizations should check, before the assessment, that their directory keeps those logs long enough to cover the audit period and that the request system and the directory use the same account identifiers, since a mismatch breaks the trace.

Before sampling begins, confirm three things with your assessor or your own control owner: the population of privileged access in scope, the sample size and selection method the assessor will use, and what counts as an acceptable validation record for your environment. Where an identity platform such as authentik or FreeIPA manages groups, the group membership history and the approver field in your request workflow become the core evidence. Where a grant bypassed the workflow, record it as an exception with a remediation date rather than backfilling a request after the fact, because a backfilled approval is easy to spot and damages trust in the rest of the evidence.

How an assessor tests Essential Eight ML1 privilege controls

This table compares, for each Maturity Level One privilege control, how an assessor tests it, what evidence they ask for and where organizations most often fall short. Use it to check your own evidence before an assessment, since a control usually fails on missing records or on a single account that breaks the rule.

Control area	Test approach	Evidence requested	Common findings
Request validation (ISM-1507)	Samples recent privileged access grants and checks that each request was validated when first made, not simply accepted by the requester's manager.	Access request tickets, approval records, validation notes and the dates they were actioned.	Grants made by email with no validation record, or privileged access approved by the person who receives it.
Dedicated privileged accounts (ISM-0445)	Compares privileged account lists against staff identities and reviews logs to confirm each privileged account is used only for privileged duties.	Account inventory, mapping of admin accounts to named individuals, and sample log extracts showing use.	Daily-use accounts that also hold admin rights, shared administrator logins, or admin accounts used to read email.
Internet, email and web restrictions (ISM-1175, ISM-1883)	Tests whether privileged accounts can browse the web, open email or reach web services, then checks any exceptions against written authorization.	Policy and configuration exports for proxy, mail and web access rules, a list of authorized exceptions with duty justification.	Admin accounts with mailboxes, admin sessions browsing the internet, or exceptions granted with no stated duty and no end date.
Environment separation (ISM-1380, ISM-1688, ISM-1689)	Attempts or reviews logons across the boundary in both directions, confirming unprivileged accounts cannot log on to privileged environments and privileged accounts cannot log on to unprivileged ones, apart from local administrator accounts.	Directory group membership, logon restriction settings, separate workstation or environment inventory and logon records.	Privileged accounts signing in to standard workstations, unprivileged users in admin groups on servers, or separate admin workstations that are not actually restricted.

Which evidence passes an ML1 privilege assessment

An assessor testing ML1 privileged access wants to see a chain of evidence: who asked for access, who approved it, which accounts exist, what groups they belong to, and how the environment prevents misuse. Each artifact below answers one link in that chain, and each goes stale quickly unless it is refreshed on a schedule.

Access request tickets with validation

Each privileged access grant should trace to a ticket that records the requester, the system or resource, the business duty, the approver, and the date validation took place. ISM-1507 expects requests to be validated when first requested, so the ticket must show validation, not just an approval click. Check that closed tickets can be matched to a live account. Refresh by reviewing new tickets against the register at least monthly, and keep the approval chain intact when tickets are closed.

Privileged account register

The register lists every dedicated privileged account, its owner, the duties it covers, and the person who approved it. ISM-0445 requires a dedicated privileged account for privileged human users that is used only for privileged duties, so the register is the first thing an assessor compares against directory exports. Any account without an owner or a linked ticket is a finding. Reconcile the register against the directory whenever accounts are created or removed, and record the reconciliation date.

Group membership exports

Exports of privileged groups, such as domain or cloud administrator roles, show who can actually exercise privilege, including nested and inherited membership. Assessors use them to confirm that only register-listed accounts appear and that no standard user account has slipped into a privileged group. Export on a fixed cadence, store the export with a timestamp, and diff each export against the previous one. In FreeIPA or similar directories, the export should include delegated administration rights as well as group membership.

Logon restriction configuration

Privileged accounts must be kept away from the internet, email and web services unless an exception is authorised, and ISM-1175 and ISM-1883 require that authorised access be strictly limited to what duties need. Evidence is the policy or directory configuration that denies these services, paired with a test showing a denied logon or browse attempt. Keep the configuration under version control so changes leave a history. Review it whenever a new web or mail service is introduced.

Proxy and mail policy exceptions

Where an authorised exception allows a privileged account to reach a web service or send mail, the exception must be written down, limited to named accounts and tasks, and expire. Assessors look for the approval, the scope, and proof that the rule is no broader than the duty. Keep an exceptions log that lists the rule, the account, the ticket and the review date. Review every exception on a set schedule and remove those whose duty has ended.

Environment separation settings

ISM-1380, ISM-1688 and ISM-1689 require separate privileged and unprivileged operating environments, and prevent unprivileged accounts from logging on to privileged ones. Evidence includes the workstation or virtual desktop build records, the logon policy that blocks cross-environment sign-ins, and a test log of a rejected attempt. Local administrator accounts are the stated exception to the reverse rule, so document them separately. Re-check these settings after each image rebuild, because a new build can silently restore default logon rights.

What meeting ML1 privilege restriction costs in money and effort

This table breaks down the money and effort behind meeting the ML1 privileged access controls, showing who is paid, whether each cost is one-time or recurring, and what changes it. No price is given here, because costs depend on the size of the estate, the identity stack already in place and the scope agreed with any outside help. Read it as a checklist for asking quotes and sizing internal time.

Cost component	One-time or recurring	What drives it	How to reduce it
Identity tooling or licences	Recurring (commercial) or one-time setup (open source)	Number of users and privileged accounts, directory and SSO licensing already held, and whether provisioning and certification features sit in a paid tier	Reuse existing directory and identity licences where they cover the need, or deploy self-hosted open-source tools such as authentik, FreeIPA and midPoint, which remove licence spend but still need hosting and support time
Engineering time for account and group redesign	One-time	Number of shared and existing administrator accounts to split into dedicated privileged accounts, and how many systems rely on local administrator access	Inventory privileged accounts first, then migrate in waves by system tier so each wave is tested before the next starts
Access request workflow setup	One-time, with ongoing change requests	Number of approvers, whether requests are validated against a defined business need, and how the workflow links to ticketing or the identity platform	Use one request path with defined approvers and reuse the existing ticketing system instead of building a separate portal
Separation of privileged and unprivileged environments	One-time build, then recurring patching	Number of privileged users, whether separate workstations or virtual machines are needed, and how much of the network must block internet and email for privileged accounts	Start with the privileged roles that have the widest reach and confirm the ML1 scope with the assessor before building more environments
Evidence upkeep	Recurring	How often access lists are reviewed, how request records are kept, and whether evidence is gathered by hand or exported automatically	Automate exports of group membership and request records, and schedule access reviews on a fixed calendar
Assessor sampling	Recurring at each assessment	Number of privileged accounts and requests the assessor samples, and how well records line up with account changes	Keep requests, approvals and account changes linked in one record so samples can be traced quickly
External review or consultant support	One-time or periodic, depending on scope	Whether help is needed for design, migration, evidence preparation or an independent check, and how many systems are in scope	Agree a fixed written scope before work starts, and ask each quote to state what it covers and what the organization must do itself

Who owns privilege controls, who prepares evidence, and who assesses them

Your organization owns the privileged access controls. Nobody else can decide who holds administrative rights, approve an exception to the dedicated account rule, or accept the residual risk of a privileged role. These decisions sit with named owners in security, IT operations and the business units that depend on the systems. An implementation partner can draft the process, but your staff must run it day to day and keep it current.

Access approval: Named approvers decide whether each privileged request is justified, record the reason and set the duration.
Account ownership: Each dedicated privileged account has an accountable owner who is responsible for its use.
Periodic reviews: Your staff run the review of privileged role holders and remove access that no longer fits the duty.
Exception decisions: Only an accountable manager can approve any deviation from the separation rules, and the approval must be recorded.
Policy and procedure: The organization publishes and maintains the privileged access policy and the operating procedures.

Confirm that each control in your scope has a named owner, a backup owner and a documented review cadence before any outside party starts work.

Where ML1 privilege programs usually fall short

Most organizations that claim Maturity Level One for privileged access have the right controls on paper but not in daily practice. The gaps below cluster around who holds privilege, how it is requested and approved, and whether privileged and unprivileged work is actually separated. Each card pairs a gap with the action that closes it.

Shared administrator accounts

When several engineers sign in with one administrator account, no log entry can tie a privileged action to a person. ML1 expects privileged human users to hold a dedicated privileged account used only for privileged duties (ISM-0445). Check your directory for generic admin names and for accounts whose passwords are known to more than one team. Replace each shared account with named accounts, then confirm that every privileged event in your logs maps to one person.

Administrator accounts used for browsing

A privileged account that also reads email, opens web pages or downloads files exposes admin rights to phishing and drive-by malware. ML1 requires that privileged accounts be kept from the internet, email and web services unless explicitly authorized, and limited to what duties require (ISM-1175, ISM-1883). Review whether any admin identity can open mail or a browser on the same device it uses for administration, and move those tasks to an unprivileged account.

Privilege granted without recorded validation

Admin rights often arrive through a phone call, a chat message or a ticket that nobody reviewed. ML1 requires that requests for privileged access be validated when first requested (ISM-1507). Confirm that every grant has a request, a named approver who is not the requester, and a stated business reason. Make the approval record the input to the account, so that an administrator cannot exist without one.

Stale administrator rights

Privilege accumulates when people change roles and nobody removes their old rights, and when temporary project access never expires. Such leftover rights are the first thing an attacker inherits from a compromised account. Run a periodic review of every group that carries administrative rights, and ask the owner of each one to confirm the access is still needed. Scheduled access certification campaigns, such as those in midPoint, can formalize this with designated reviewers who keep, change or revoke each item within a set timeframe.

Environment separation applied only on paper

Many policies say privileged work happens in a separate environment, while in practice administrators run tools from their everyday desktop. ML1 requires separate privileged and unprivileged operating environments, with unprivileged accounts unable to log on to privileged environments (ISM-1380, ISM-1688, ISM-1689). Test this directly: attempt a privileged logon from a standard workstation session and check whether the environment blocks it. Document the result and retest after every build change.

Questions buyers ask about ML1 privilege controls

How much effort does Maturity Level One privileged access take?

Effort at ML1 depends mostly on how many privileged accounts, systems and administrators the organization has, and how many of its privilege processes already exist in writing. The controls are not conceptually large: a validated request process, a dedicated admin account for each privileged person, restrictions on internet, email and web access for those accounts, and separate privileged and unprivileged environments. The heavy work is usually discovery, meaning finding every account that holds privilege, and then changing daily habits. Ask any provider to break its quote into discovery, design, configuration, testing and evidence collection, so you can see where the hours go.

Can we implement ML1 privileged access controls in-house?

Yes, many organizations do, provided the internal team understands directory services, endpoint management and the assessment evidence an auditor will request. The work is mostly configuration and process change, not new products. The points where in-house teams most often stall are the request validation workflow, which needs an approver who is not the requester, and the separation of privileged environments, which can involve rebuilding workstations and changing how staff log on. An outside partner can take on the parts your team lacks capacity for, but the organization still owns its policies, approvals and access decisions.

What does ML1 require from the IT team day to day?

The IT team needs to run privileged access as a process rather than a one-off project. Day to day, that means approving or rejecting privileged requests against a documented need, keeping a record of who was granted which privilege and when, and ensuring administrators sign in with their dedicated privileged account only for privileged tasks. Engineers also need to know which environment they are working in and to avoid using admin accounts to browse the web or read email. Plan for periodic reviews of who still holds privilege, because access tends to accumulate over time.

How long does it take to reach ML1 for privileged access?

ASD's materials do not set a duration for reaching ML1, so treat any published timeline with caution. The schedule depends on the number of privileged accounts, how many systems they reach, whether directory and endpoint tooling already supports separate accounts, and how quickly approvers and change boards can act. Organizations with clear ownership of identity systems and a small administrator population move faster than those with shared admin credentials spread across many systems. Ask for a timeline in the written scope that lists the discovery, configuration and evidence phases separately.

Can an implementation partner prepare the evidence for ML1 privileged access?

A partner can prepare systems, configuration records, request workflows, account inventories and test results that show how the controls operate. That evidence is what an assessor reviews. The partner does not decide whether the organization meets ML1, and it does not issue a report or certificate. Assessment is performed by the organization's own assessors or an independent party the organization engages. When you compare providers, ask which evidence artifacts they will deliver, who owns the evidence after handover, and how they will keep it current between assessments.

Is there an ASD certificate for Essential Eight ML1?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, so there is no ASD certificate for reaching ML1. Maturity is shown through an assessment of how each strategy is implemented and how well it works against the maturity model. Be cautious with any vendor or consultant who offers an Essential Eight certificate, and ask them who issues it and under what authority. Your evidence pack, assessment record and internal approvals are what demonstrate the level to customers, regulators and auditors.

Which open-source tools help with ML1 privilege controls?

Directory and identity tools can enforce much of the ML1 access model. FreeIPA stores users, groups and hosts in a central directory with delegated administration, which helps separate who can grant privilege. authentik's SCIM provider can push user and group changes to target applications and deprovision users when they lose access, which supports timely removal of access. midPoint access certification campaigns let designated reviewers decide whether to keep, change or revoke access items on a set schedule. Confirm each tool's fit with your environment and with the ISM profile controls before you rely on it.

How DeployOpen scopes and prepares ML1 privilege evidence

DeployOpen works on Restrict administrative privileges at Maturity Level One inside the client's own infrastructure, starting from a written scope that names the systems, accounts and ISM controls in play. We prepare the systems and evidence an assessor will examine, while the organization owns its controls and any independent assessor issues the assessment outcome.

How we scope

Agree in writing which privileged accounts, systems and admin workflows fall inside the ML1 privilege scope.
Map each in-scope system to the ML1 privilege controls, including request validation and dedicated privileged accounts.
Confirm which environments are in scope, such as cloud accounts, data centers or air-gapped networks, before work starts.

How we build

Configure separate privileged and unprivileged operating environments and block privileged accounts from internet, email and web access.
Set up directory and identity services so privileged access requests are recorded and validated before they are granted.
Test each control against its expected behavior and record the results for the assessor to review.

How we hand over

Document the configured controls, owners, procedures and the evidence each control produces.
Provide a control-to-evidence register that the organization's assessor can trace back to each ISM control.
Walk the internal team through the runbooks so they can operate and re-test the controls after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
Retainers can cover periodic review of privileged accounts and re-validation of access request records.
Confirm the support terms, response expectations and review cadence in the written agreement before work begins.