Restrict administrative privileges maturity level 3: requirements and evidence

What Essential Eight ML3 requires for restricted administrative privileges

An organization preparing for an ML3 assessment needs to know what privileged access must look like in practice: privileges limited to what each user needs for their duties, just-in-time administration, administrative work done from Secure Admin Workstations, and credentials protected by Windows features that block theft. The risk behind these requirements is credential theft combined with privilege accumulation. An attacker who obtains a standing administrator credential, or a user who has collected role after role over the years, can move across systems far beyond the job the account was created for. ASD's ISM v2026.09.4 Essential Eight profiles tag ISM-1508 and ISM-1649 at ML3 for limiting privilege to duties and using just-in-time administration, and ISM-1898 for Secure Admin Workstations.

ML3 builds on ML2. In the ISM v2026.09.4 Essential Eight profiles, every ML2 control remains at ML3 except three, ISM-1691, ISM-1695 and ISM-1873, which ML3 replaces with stricter versions. So the 45 day inactivity limit, the 12 month revalidation limit, jump servers and central logging of privileged events all still apply. Confirm the exact wording of the replacement controls in the ISM OSCAL catalog before you write your assessment plan, because the stricter versions, not the older ones, are what an assessor will test.

The hard part is usually operational habit, not tooling. Tools can enforce just-in-time elevation, store admin accounts separately and enable credential protection, but the organization still has to route every administrative task through those paths, retire standing rights when a project ends and review who holds access on a fixed schedule. Ask your team to name the people who can currently administer your domain controllers, hypervisors and cloud tenant, then check whether each one can explain why they need that access today. Credential protection features such as Credential Guard, Remote Credential Guard and Local Security Authority protection (ISM-1686, ISM-1897, ISM-1861) need to be enabled and verified on every device in scope, so plan for exceptions and document them.

Which privileged accounts, systems and teams fall under ML3

Scope decides how much work ML3 becomes. The ISM Essential Eight ML3 profile applies its privileged access and logging expectations to every system and account the organization assigns to that profile, so the first task is deciding which accounts, hosts and teams sit inside the boundary. The cards below cover the decisions that most often change the size of the job.

Domain and cloud administrator roles

Identity and cloud tenant roles, such as directory domain administrators and cloud global or subscription owners, usually sit at the top of the privileged inventory. Each role assignment, including groups that nest privileged roles, needs an owner and a documented need. Ask whether any role is assigned permanently and whether it can be activated only when needed. Standing assignments here are the first thing an assessor will test against ISM-1508 and ISM-1649.

Server administration accounts

Server administration is where scope tends to grow fastest, because ML3 timely log analysis extends beyond internet-facing servers to non-internet-facing servers. Inventory local administrator groups, service accounts with interactive logon and remote management paths. Internal servers that were out of scope at ML2 may now require the same logging and review. Confirm which servers are internet-facing, since that single attribute changes the logging workload.

Workstation administration

ML3 brings workstations into the logging expectation as well as the privileged access one. Administrators who hold local admin rights on laptops or who use a workstation for both email and privileged work create a boundary problem. Identify which staff use one device for both roles, and whether they can be moved to a separate Secure Admin Workstation. The ISM tags the Secure Admin Workstation requirement at ML3, so this group is where that control is most likely to bite.

Vendor and managed service accounts

Vendor, managed service provider and break glass accounts often sit outside the internal identity process. Each one that can change configuration or read logs belongs in the privileged inventory. Ask for the vendor's access method, who approves each session and how credentials are rotated after the engagement ends. Contracts should state where the logs go. Confirm this with each provider, because their practices determine whether the organization can evidence control.

Teams with standing privilege

Some teams hold privilege by habit rather than by design, such as application support groups that have been administrators for years or on-call engineers with permanent domain rights. Map each team to the systems it touches and the reason it needs privilege for each task. Shared administration accounts used by several people make attribution impossible and should be listed as a scoping item in their own right. Expect the largest effort here, because removing standing access changes how people work.

Scope drivers and their effort

Two attributes shape effort more than any other: whether a system is internet-facing and whether administration is shared. Internet-facing systems and shared accounts raise logging, review and attribution work together. Document the scope boundary in writing, record the reason each system is in or out, and agree the method with your assessor before evidence collection begins. Ask any implementation partner to price the work from this written inventory rather than from an estimate.

How just-in-time administration and Secure Admin Workstations work together

At Maturity Level Three, the ISM Essential Eight baseline tags two privileged access expectations that work as a pair: ISM-1508 requires that privileged access be limited to what users need for their duties, and ISM-1649 requires that just-in-time administration be used. In practice, standing privilege gives way to time-bound elevation. Administrators no longer hold privileged group memberships or roles around the clock. They request elevation for a specific task, receive it for a bounded window, and lose it when the task ends. The organization owns the decisions that make this work: which roles are eligible for elevation, who approves each request, how long an elevation may last, and which systems fall within scope. An implementation partner can configure the tooling that enforces those decisions, but the policy itself must be set and approved internally.

ISM-1898 adds the second half of the pair. Secure Admin Workstations must be used for administrative activities, so the elevated session runs on a dedicated, hardened workstation rather than the same device used for email, web browsing and documents. Administrators therefore keep two identities and two environments: an ordinary account for daily work and a privileged account used only from the admin workstation. The day-to-day change is mostly procedural. Administrators stop running privileged consoles from their everyday laptop, they expect an approval step before elevating, and they accept that some tasks wait until the workstation is available. Before rollout, confirm with your assessor how they will test ISM-1898 and which workstation configuration evidence they expect, since the ISM text and its supporting guidance define the detail.

Several ML2 controls remain in force at ML3 and carry much of the evidence for this pair. ISM-1648 and ISM-1647 cover inactivity and revalidation limits for privileged access, and ISM-1387 and ISM-1509 cover jump servers and central logging of privileged events. Logs from elevations and admin workstation sessions are the proof that just-in-time and workstation rules were followed, so plan log retention and review before go-live. Check that elevation requests, approvals and session records are retained centrally and can be produced for each sampled administrator. The ISM OSCAL catalog lets your team confirm the exact control wording and tags against your own control register.

Which Windows credential protections an ML3 assessor will check

At Maturity Level Three, the Essential Eight baseline ties credential protection to three Windows features: Local Security Authority protection, Credential Guard and Remote Credential Guard. The ISM controls tagged ML3 for these features are ISM-1861, ISM-1686 and ISM-1897. An assessor will expect each feature to be enabled on the systems in scope and will ask how you know. The aim is to make it harder for an attacker who has already reached a machine to lift password hashes or Kerberos tickets from memory and reuse them to reach privileged accounts elsewhere.

Local Security Authority protection runs the LSA process as a protected process so that code without the right signing cannot read its memory. Credential Guard isolates derived credentials in a virtualization-based security environment so the host operating system cannot read them directly. Remote Credential Guard keeps credentials on the client during Remote Desktop sessions so they are not exposed on the remote host. Each feature has its own prerequisites, including hardware virtualization and firmware support, specific Windows editions, and in some cases licensing or compatibility limits for drivers and applications. Confirm each prerequisite against Microsoft's current documentation and test the feature on your own hardware images before you rely on it, because support can differ by device model and edition.

Enabling a setting is not the same as showing it working across the fleet. Group Policy or Intune may report a policy as applied while a subset of devices has failed to start the protected services, or while an older driver blocks Credential Guard from running. Ask for evidence that shows the running state on each in-scope device, such as an export from your endpoint management tool or a query result from a fleet tool, and keep the exceptions with a documented owner and reason. Your independent assessor will sample devices and check the live configuration, so plan a recurring check rather than a one-time configuration screenshot.

How to sequence the ML3 privileged access work

The sequence moves from knowing which privileged roles exist to proving, on a recurring basis, that each one is still needed and still controlled. Each step produces an artifact that the next step depends on, so an assessor can trace a privileged account from its role definition to its review record.

Inventory privileged roles and holders
List every role, group, local administrator right, service credential and cloud subscription role that grants elevated capability across identity, endpoints, servers, applications and networks. Record who or what holds each one and why. The owning team, usually identity and access management working with system owners, does this work. The step is done when every privileged assignment maps to a named role, a named owner and a documented business need, and the list is stored where it can be reviewed later.
Reduce standing privileged access
Remove privileges that the inventory shows are unused, duplicated or broader than the duties require. Split broad administrator roles into narrower ones where the platform allows it, and confirm that each remaining standing assignment has a justification. This work usually needs sign-off from system owners because some removals will break routines. The output is a revised role model in which standing privilege covers only what users need for their duties, the change record for each removal, and a list of exceptions with an owner and a reason.
Deploy just-in-time elevation
Configure a controlled way for administrators to activate elevated rights for a limited time, with an approval or justification step and a record of each activation. Move the reduced standing assignments that were confirmed in the previous step into this model. Confirm with the vendor of your identity platform which elevation features it supports and how activations are logged, because capability varies between products. The step is complete when administrators perform privileged work only through elevation, and activation records can be pulled for any date range.
Build or designate Secure Admin Workstations
Identify the devices used for administrative activity and separate them from general-purpose use. A secure admin workstation is a dedicated device or environment that is not used for email or general browsing, and it should be managed under a separate configuration baseline. Platform and security engineering teams usually own this, with the administrators themselves involved in testing. The step is done when every administrative session in scope runs from a designated device, the device baseline is documented, and a test confirms that administrative tools cannot be reached from ordinary user sessions.
Enable Windows credential protections
Turn on Local Security Authority protection, Credential Guard and Remote Credential Guard on the endpoints and servers that the ML3 controls cover, after confirming application compatibility. Endpoint administrators apply these through their management tooling, and a pilot group should precede broad rollout. The output is a configuration report showing each protection enabled or excepted on each device class, with every exception carrying an owner and a reason. Where a platform cannot support a protection, record that as a documented exception rather than leaving the gap undocumented.
Extend log analysis beyond internet-facing servers
Expand the timely review of security event logs from internet-facing servers to non-internet-facing servers and workstations, as the ML3 baseline requires. Confirm that privileged events from the earlier steps reach central logging, then assign analysts and define how alerts are triaged. Security operations usually owns this work. The step is done when logs from the in-scope population are collected centrally, an alerting rule covers privileged activity, and the review cadence and responsible roles are written down.
Set up recurring access reviews
Schedule periodic reviews in which designated reviewers confirm, change or revoke each privileged assignment, and set a deadline for every decision. Reviews work best when they draw from the inventory created in the first step, so the reviewer sees the current state. Compliance and system owners run the cycle, and the review records become part of the evidence set. The sequence is complete when at least one full review cycle has closed, every revoked or changed assignment shows a matching change record, and the next review date is scheduled.

How an assessor tests ML3 privileged access

This table compares each Maturity Level Three privileged access expectation with what an assessor tests, the evidence they ask for, and the findings that appear most often. Read each row as a test plan: the assessor samples accounts, traces elevations, inspects workstations and checks credential protection settings. The main takeaway is that ML3 is judged on operating evidence over time, not only on configuration written down in a policy.

Expectation	What the assessor tests	Evidence requested	Common findings
Least privilege for privileged access	Samples privileged accounts and checks that each holds only the rights its duties need, with no standing access beyond the role	Role and group membership exports, documented duty statements, recent access review records with reviewer decisions	Broad domain or tenant roles granted for convenience, shared admin groups, reviews that approve everything without change
Just-in-time administration	Traces a sample of privileged elevations to confirm they are requested, time-limited, approved where required and removed afterward	Elevation or PIM activation logs, approval records, timestamps showing expiry, sample tickets linked to each activation	Permanent administrator assignments left in place, activations with no linked business reason, expiry not enforced
Secure Admin Workstations	Inspects the devices used for administrative work to confirm they are dedicated, locked down and not used for email or general browsing	Device inventory showing admin-only assignment, build or configuration baseline, policy assignments, sample device configuration reports	Admins performing tasks from ordinary daily-use laptops, exceptions not recorded, drift from the approved build
Credential protection	Reviews whether Local Security Authority protection, Credential Guard and Remote Credential Guard are enabled on in-scope systems and whether settings are enforced rather than optional	Configuration or compliance reports for sampled endpoints, group policy or device management settings, exception register	Features enabled on a subset of devices only, features disabled for compatibility without approval, no check after rollout
Timely log analysis of privileged and wider events	Checks that events are collected from internet-facing and non-internet-facing servers and workstations and that analysis happens within a defined timeframe	Log source coverage list, alert or review records, examples of triaged privileged events, documented review cadence	Logging enabled only on servers, reviews happening only when an incident occurs, gaps in collection that nobody has noticed
Inactivity and revalidation limits	Samples accounts to confirm inactive privileged access is disabled and that access is revalidated on schedule	Account last-logon reports, revalidation records, disablement history	Dormant admin accounts still enabled, revalidation completed without evidence of a decision

Evidence that passes an ML3 privileged access review

An assessor tests Restrict administrative privileges at ML3 by sampling privileged accounts and asking for records that show who holds access, how it was granted, and how it was watched. The six artifacts below connect those questions, and each one goes stale quickly unless it is refreshed on a schedule rather than rebuilt before an audit.

Privileged role inventory

A current list of every account and group that holds administrative rights across directories, hypervisors, cloud consoles, databases and network devices, with the owner, business justification and the ISM controls it supports. At ML3 the inventory must show access limited to what each user needs for their duties (ISM-1508 and ISM-1649). Keep it current by generating it from directory exports on a fixed cadence and diffing each run against the last, so unexpected additions appear as exceptions rather than surprises at audit time.

Just-in-time elevation logs

Records showing each time a privileged role was activated, who requested it, the approved duration, the approver and the stated reason. Assessors use these to confirm that standing administrative rights are not the norm and that ML3 just-in-time administration (ISM-1649) actually operates. Check that each elevation has a matching ticket, that elevations expire on schedule, and that no account bypasses the workflow with a permanent assignment.

Secure Admin Workstation configuration baseline

The documented build and policy settings for the dedicated machines used for administrative activities (ISM-1898), together with evidence that they are the only devices permitted to perform those tasks. The baseline should cover operating system version, restricted internet and email access, application allow-listing and patch status. Store the baseline in version control, scan endpoints against it regularly, and record every exception with an owner and an expiry date.

Credential protection status reports

Per-device reports confirming that Local Security Authority protection, Credential Guard and Remote Credential Guard are enabled where ML3 requires them (ISM-1861, ISM-1686, ISM-1897). Assessors look for the configuration state and for proof it is enforced, not just deployed. Collect the status from a configuration assessment on a schedule, track devices that fall outside the baseline, and retain the failing results alongside the remediation tickets that closed them.

Access certification records

Completed review campaigns in which designated reviewers decided whether to keep, change or revoke each privileged role assignment within a set timeframe. These records show that access accumulation is checked and that segregation of duties is maintained. Keep the campaign definition, reviewer list, decisions, and evidence of any revocations that followed. Run reviews on a cadence shorter than the ML2 revalidation limit so the records reflect current access.

Privileged event logs and log review records

Central logs of privileged activity, along with dated records showing that someone reviewed them. ML3 extends timely event log analysis from internet-facing servers to non-internet-facing servers and workstations (ISM-1907, ISM-0109), so the log sources must cover the whole estate. Confirm log retention and integrity, and keep review sign-offs that name the reviewer, the period covered and the findings raised. An assessor will often pick a privileged action and trace it through both the log and the review.

What meeting ML3 privileged access costs in money and effort

This table breaks down the cost components of meeting ML3 privileged access, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. No figures are given because none are supplied for this topic, so use the questions in the last column to request quotes that compare like with like. Open-source tooling can remove licence spend in some areas, but engineering and assessment effort remain.

Cost component	One-time or recurring	What drives it	What to ask for in a quote
Identity and privilege tooling	Recurring licence or support, plus one-time setup	Number of privileged accounts, whether just-in-time elevation is needed, and whether Entra PIM or a comparable product is already licensed	Itemised licence terms, tiers that include just-in-time workflows, and any per-user or per-privilege fees
Access certification and review	Recurring, per review cycle	Number of role assignments, count of designated reviewers, and how often the 45 day inactivity and 12 month revalidation limits are checked	Reviewer workload estimate, campaign tooling included, and how revocations are evidenced
Dedicated admin hardware for Secure Admin Workstations	One-time, with refresh cycles	Number of administrators, device model requirements for credential protection features, and whether devices are issued or reused	Device specification, procurement and imaging labour, and the refresh plan
Engineering time for elevation and SAW workflows	One-time build, then recurring maintenance	Number of administrative tiers, integration with existing identity systems, and exceptions for break glass and managed service accounts	Named deliverables, test evidence, and who maintains the workflow after handover
Credential protection rollout	One-time, with ongoing validation	Hardware and operating system compatibility, legacy applications that break under protection, and testing across the estate	Compatibility test plan, rollback steps, and the evidence that protection is enabled on each device
Log analysis effort for non-internet-facing servers and workstations	Recurring	Event volume, number of endpoints now in scope, and whether alerts are triaged by staff or a managed service	Alert triage process, staffing assumptions, and the retention period for privileged event logs
Central logging platform	Recurring hosting and storage, plus one-time setup	Log volume, retention length, and whether the platform is self-hosted in the client's infrastructure	Storage sizing assumptions, backup of the log store, and who holds administrative access to it
Assessor sampling and evidence preparation	Recurring, per assessment	Number of systems and accounts sampled, quality of existing evidence, and how often evidence must be regenerated	Evidence list mapped to ISM control IDs, sampling approach, and what the assessor needs from the organization
Open-source tooling (self-hosted)	Licence cost removed, infrastructure and staff time remain	Operating platform hosting, patching of the tool itself, and skills needed to run it in-house	Support model, upgrade responsibility, and which components are not covered by a licence

Who owns the ML3 privileged access work and who can help

Your organization owns the privileged access controls and the behavior they govern. Only your people can decide who holds administrative rights, approve exceptions, enforce the rule that administrators use dedicated workstations, and answer for what happens when a privileged session goes wrong. A partner can build the machinery, but the decisions and the daily discipline stay in-house, and an assessor will ask staff, not vendors, how the process works.

Role and approval decisions: Define which roles need privileged access, who approves each request, and how long each grant lasts.
Admin behavior: Make sure administrators actually use Secure Admin Workstations and just-in-time elevation, and handle exceptions through a documented route.
Access reviews: Run periodic reviews of privileged accounts and record the decisions made.
Incident and exception ownership: Own the response when a privileged credential is misused or a control is bypassed.
Evidence custody: Keep the logs, review records and configuration exports that prove the controls operate.

Confirm with your security lead which named role owns each ML3 requirement before you invite any outside party into the work.

Where ML3 privileged access programs usually fall short

Most organizations that reach the privileged access requirements at Maturity Level Three already have some of the controls in place. The gaps tend to sit at the edges: where old access survives next to new, where protections cover only part of the estate, and where records are kept but nobody reads them. Each card below names one gap and the step that closes it.

Standing admin rights kept beside just-in-time

Just-in-time administration under ISM-1508 and ISM-1649 only reduces exposure if standing privileges are removed. Many programs add a time-limited elevation path but leave the permanent admin group membership untouched, so an attacker with a single account still holds full rights. Check whether any user or service account keeps a permanent privileged role that the elevation workflow was meant to replace. Remove those memberships, then confirm that elevation is the only route to the role.

Admin tasks run from ordinary workstations

ISM-1898 requires Secure Admin Workstations for administrative activity. Teams often route administrators to a hardened workstation for a few tasks while the rest, including browsing, email and document editing, still happen under the same privileged session on a general-purpose laptop. Inventory which administrative tools run outside the dedicated device, including remote consoles and scripts. Move those tasks onto the Secure Admin Workstation and block general internet and email use from it.

Credential protection on some hosts only

The ML3 credential protection controls (ISM-1861, ISM-1686 and ISM-1897) ask for Local Security Authority protection, Credential Guard and Remote Credential Guard to be enabled. In practice these features are often switched on for a pilot group or the newest build image, while older servers and legacy workstations keep the default settings. Pull a configuration report from the device management tool and list every host where each feature is disabled or unsupported. Record the exceptions with a dated owner, then close them or document why the host cannot meet the requirement.

Privileged log events nobody reviews

Central logging of privileged events, a ML2 control that stays in force at ML3, is only useful when someone examines the events in time to act. Many environments collect the logs but have no defined review cadence, no alert on sensitive events such as new privileged group membership, and no record of who looked at what. At ML3 the review also extends to non-internet-facing servers and workstations under ISM-1907 and ISM-0109. Define which events trigger an alert, assign a reviewer, and keep a dated record of each review.

Service and break glass accounts outside the inventory

Service accounts, managed service provider accounts and break glass credentials often sit outside the normal identity lifecycle. They may have no named owner, no 45 day inactivity rule and no revalidation date, which the ML2 controls ISM-1648 and ISM-1647 expect to apply. Build a single register of these accounts with their purpose, owner, privilege level and location of stored credentials. Then confirm that each one is covered by inactivity disabling and periodic revalidation, or that a documented exception explains why not.

Access reviews that do not revoke

A periodic access review only changes risk if the reviewer's decision results in removal. Some programs run the review on schedule, record approvals for nearly every entry and never act on the revocations the reviewer marks. Access campaigns in midPoint are designed to have reviewers keep, change or revoke each item within a set timeframe, which makes the outcome visible. Track each revoke decision to completion in the identity system, and report the number of items that were removed rather than only the number that were reviewed.

Questions buyers ask about ML3 privileged access

Does Maturity Level 3 require a Secure Admin Workstation for every administrator?

Not necessarily for every administrator, but the requirement is tied to the activity, not the person. ASD's ISM v2026.09.4 Essential Eight profiles tag ISM-1898 at ML3, which says Secure Admin Workstations must be used for administrative activities. The practical question is therefore which administrative tasks your organization classifies as privileged, and whether each of those tasks is performed from a dedicated, hardened device. Scope the workstation population from your privileged access inventory, then confirm the exact control wording and any applicability notes with your assessor, because interpretation of scope is an assessment decision.

What does the internal team have to do during an ML3 privileged access project?

Your internal team owns the controls, so it must make the decisions that only the organization can make. These include naming which roles are privileged, deciding who approves just-in-time elevation, setting review owners for access certification, and accepting risk where a technical control cannot be applied yet. Engineers also need to administer the identity platform, endpoint policy and logging pipeline after handover. A partner can build and document the configuration, but staff who will run it day to day should take part in design reviews and test changes in a non-production environment before they reach production.

Can an implementation partner prepare the evidence an assessor will review?

Yes, a partner can prepare systems, configuration records and evidence packs, but it cannot issue the assessment result. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate. Maturity is judged by an assessor reviewing how each strategy is implemented and whether it works. A partner can help map ISM controls to the configuration that satisfies them, capture exports of settings and logs, and document test results. Ask the partner to state in writing which artifacts it produces and which decisions remain with you and your assessor.

How long does ML3 privileged access work take?

Duration depends on scope and is set in the written plan agreed before work starts. The main drivers are the number of privileged roles, the number of administrative devices, how much of the identity and endpoint estate is already centralized, and whether logging for non-internet-facing servers and workstations must be extended. Each of these changes the number of configuration changes and test cycles. Ask for a phased plan that separates design, pilot, rollout and evidence capture, and check that the plan states which phases depend on your change approval windows and staff availability.

Can Credential Guard be turned on across every device at once?

Usually not safely. ML3 credential protection controls ISM-1861, ISM-1686 and ISM-1897 require Local Security Authority protection, Credential Guard and Remote Credential Guard to be enabled, but enabling them everywhere in one change creates avoidable risk. Some applications, drivers and legacy integrations may depend on behavior these features change. A safer sequence is to inventory devices and dependencies, pilot on a representative group, record failures and exceptions, then roll out in rings. Confirm the exact configuration and any documented exceptions with your assessor before you declare the control implemented.

Can open-source tools produce the evidence for ML3 privileged access?

Open-source tools can produce much of the evidence, but they do not decide compliance on their own. midPoint (EUPL-1.2+) runs access certification campaigns in which designated reviewers keep, change or revoke role assignments within a set timeframe, which supports least privilege and segregation of duties. Wazuh (GPL-2.0-only) Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation. Fleet (MIT) policies, which are osquery queries, show which devices pass or fail each check. Nextcloud (AGPL-3.0-only) admin_audit writes administrative events to audit.log. Confirm each tool's fit with your assessor and check that its outputs are retained and tamper-protected.

How DeployOpen scopes and prepares ML3 privileged access evidence

DeployOpen plans, implements and documents the privileged access controls for Maturity Level Three inside your own infrastructure, using self-hosted open-source platforms where they fit. We prepare the systems and evidence an assessor will review, while your organization keeps ownership of its controls and any independent assessor issues the conclusions.

How we scope

Engagements are fixed-scope, with the systems, privileged roles and deliverables agreed in writing before work starts.
The written scope lists which ML3 privileged access controls are in and out, including just-in-time administration and Secure Admin Workstations.
We confirm which environments hold privileged accounts, such as Windows domains, cloud tenants and Linux hosts, and which evidence each one must produce.

How we build

We configure credential protection features such as Credential Guard and Remote Credential Guard on the Windows estate in scope.
We set up just-in-time elevation and Secure Admin Workstation builds, then test that privileged sessions follow the agreed workflow.
We deploy self-hosted tooling for access certification, configuration checks and central logging of privileged activity, with each control mapped to its ISM identifier.

How we hand over

You receive documentation of configurations, role designs, test results and the evidence location for each ML3 control in scope.
We walk your security and IT teams through the recurring reviews needed to keep the privileged access evidence current after handover.
Your assessor or certification body decides whether the controls meet the maturity model, since DeployOpen prepares evidence but does not issue assessments.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
A retainer can cover re-running access certification campaigns and reviewing configuration drift between assessment cycles.
Ask any partner to confirm in writing which recurring tasks sit with your team, which sit with them, and which sit with the assessor.