What Essential Eight ML2 asks for in privileged access
At Maturity Level Two, the Essential Eight asks you to show that privileged access is not only granted carefully but also removed when it is no longer needed, administered through controlled paths, and recorded centrally. The compliance lead's test is operational: can you produce evidence that these controls ran during the assessment period, not just that the policy describes them. ML2 builds on everything ML1 requires, so the ML1 baseline (validated requests, dedicated privileged accounts and separated environments) must already be working before ML2 is credible. Accumulated privilege is the core risk here. Administrators change roles, contractors finish projects, and service accounts outlive the systems they were built for. Each unused right is a path an adversary can use without tripping an alarm, and if nobody logs those rights or their use, nobody notices the path exists.
The ML2 baseline in ASD's ISM OSCAL profiles adds seven privileged access controls to the ML1 set: ISM-1648 and ISM-1647 cover lifecycle, ISM-1687 and ISM-1387 cover separation of privileged environments and administrative paths, ISM-1685 covers credential strength and management for break glass, local administrator and service accounts, and ISM-1509 and ISM-1650 cover central logging of privileged access and of privileged account and security group changes. Read the control text in the ISM catalog itself rather than relying on a summary, and confirm the wording against the profile version your assessor uses. Start by inventorying every privileged account, group and service identity, then check each control against the systems that hold them, because most gaps appear in service accounts and legacy directories that were never added to a review process.
The Essential Eight is a set of mitigations, not a certification scheme, so there is no ASD certificate to obtain. Maturity is shown through an assessment of how each strategy is implemented and how well it works against the maturity model, and the evidence for these controls is what an assessor will sample. An implementation partner can help configure systems and collect that evidence, but the organization owns the controls and the assessor draws the conclusion. Confirm with your assessor which evidence format and sampling period they expect before you start building the record, so that logs, review decisions and account disablement records are retained in a form that can be tested.
Which accounts, systems and teams fall under ML2 privileged access
Maturity Level Two privileged access controls apply to every account and environment that can change security, identity or infrastructure settings, so scope is the first decision that sets the workload. The cards below cover the account types, access paths and third parties that most often decide how many accounts and log sources an assessor will expect you to evidence.
Domain and cloud administrator accounts
Domain administrators, cloud tenant administrators and global administrators sit at the top of the privilege chain, so each standing role assignment is a finding waiting to happen. Under ISM-1648 and ISM-1647, every one of these accounts must be disabled after 45 days of inactivity and after 12 months without revalidation. Inventory every directory and cloud tenant role, including those granted to groups, because group membership changes the account count without changing the role. Confirm which accounts can be disabled automatically and which need a manual review.
Local administrator and service accounts
Local administrator accounts on endpoints and servers, and service accounts running applications or scheduled tasks, often multiply quickly and are easy to miss in scope. ISM-1685 requires their credentials to be long, unique, unpredictable and managed, which means a fleet of shared local administrator passwords counts as a gap. Decide early whether service accounts are in scope as privileged accounts, since that choice determines how many credentials and log sources you must evidence. Ask your platform team for a complete export from directory and configuration management tools.
Break glass accounts
Break glass accounts are emergency credentials that bypass normal controls when the identity provider or directory is unavailable. Because they are used rarely, their use is the event most likely to go unreviewed, so they need the same credential requirements as other privileged accounts under ISM-1685 and their use must appear in central logs under ISM-1509. Confirm where the credentials are stored, who can retrieve them, and how each use is alerted and reviewed. Document a small, named set of these accounts rather than leaving the set open ended.
Admin workstations and jump servers
Administrative activity must pass through jump servers under ISM-1387, and privileged operating environments must not be virtualised within unprivileged ones under ISM-1687. Scope decisions here determine whether administrators work from dedicated hosts, from their everyday devices, or through a bastion that brokers sessions. Each jump server and admin workstation becomes an in-scope system with its own logs, patch records and access list. Confirm which administrative paths exist, including console, remote shell and cloud portals, so none bypass the jump layer.
Third-party and managed service provider access
Managed service providers and vendors often hold privileged access that never appears in your own directory, which makes them easy to leave out of scope. Their accounts, remote sessions and tooling still fall under the privilege controls for the systems they administer, and their privileged events must reach the central log. Ask each provider to list the accounts it uses, how sessions are initiated, and where its activity is recorded. Access certification campaigns, such as those in midPoint, can include vendor role assignments so reviewers confirm them on the same cycle as internal accounts.
Log sources and event retention
Scope also sets the logs you must evidence. ISM-1509 and ISM-1650 require privileged access events and privileged account and security group management events to be centrally logged, and ISM-1815 requires those logs to be protected from unauthorised modification and deletion. Each in-scope system, including jump servers, directories and cloud consoles, adds a log source that must reach the central store. List every source before you start, because a missing one usually surfaces as a gap during assessment.
How an assessor tests ML2 privileged access controls
This table compares, for each ML2 privileged access element, how an assessor tests it, what evidence to prepare, and where organizations commonly fail. Read each row as a test plan: the left column names the element, and the cells show what the assessor will sample, reconcile and ask to see. The main takeaway is that most ML2 findings come from account lists that do not match HR and access records, not from missing tools.
| Element | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| Inactivity disabling (ISM-1648) | Pull the full privileged account list from the directory and compare last sign-in dates against the 45-day threshold. Sample accounts that show recent activity but belong to people who have left or changed roles. | Directory export with last logon dates, the automated disabling rule or script, and records of accounts disabled by it. | Rule exists but excludes service or break glass accounts, or dates are not captured for all directories. |
| Revalidation within 12 months (ISM-1647) | Select a sample of privileged accounts and ask for the most recent revalidation record for each. Confirm the approver was not the account holder. | Signed or recorded revalidation decisions, dated within the last 12 months, with the reviewer's name and role. | Revalidation is done by the same team that grants access, or accounts approved years ago carry no later record. |
| Reconciliation against HR and access records | Reconcile the privileged account list against HR joiner, mover and leaver data and the access request system. Each privileged account should trace to a current employee, contractor or approved service owner. | HR extract used for reconciliation, access request tickets, and the reconciliation output showing exceptions and their closure. | Leavers still hold privileged rights, or accounts have no named owner. Reconciliation is done once and not repeated. |
| Jump server use (ISM-1387) | Attempt or observe administrative sessions to in-scope systems and confirm they originate from the jump server. Review firewall or access rules that block direct administrative paths. | Network diagrams, jump server configuration, access rules, and session logs that show administrative traffic routed through it. | Administrators can still reach servers directly over RDP or SSH from workstations, or jump server logs are incomplete. |
| Non-virtualised privileged environments (ISM-1687) | Inspect how privileged operating environments are built and confirm they are not hosted as guests inside unprivileged environments. Check hypervisor and virtual desktop configuration for administrative workstations. | Architecture records, hypervisor inventory, and build standards for administrative environments. | Admin workstations run as virtual machines on general-purpose desktop hosts, and the design record does not mention this risk. |
| Break glass, local admin and service account credentials (ISM-1685) | Ask how credentials for break glass, local administrator and service accounts are generated, stored and rotated. Sample several accounts and check for shared or default passwords. | Password policy or generator settings, secrets management records, rotation logs, and break glass procedure with recent use records. | Shared local administrator passwords across many machines, credentials stored in scripts or repositories, or no record of break glass use. |
| Central logging of privileged events (ISM-1509, ISM-1650) | Select privileged logons and account or group changes, then trace each event to the central log store. Confirm the logs cannot be altered by administrators of the source systems. | Log source inventory, collection configuration, sample event extracts, and access controls on the log store. | Some privileged systems forward no events, or logs are retained on the same host the administrator can edit. |
| Log protection and analysis (ISM-1815, ISM-1906) | Confirm that privileged event logs are protected from modification and deletion, and that alerts from them are reviewed in a timely way. Ask who reviews alerts and how reviews are recorded. | Log integrity settings, retention configuration, alert triage records, and the review schedule with named owners. | Logs are collected but never reviewed, or review evidence exists only for a short recent window. |
Sequence for implementing ML2 privileged access controls
This sequence moves an organization from an unmanaged set of privileged accounts to a state where ML2 privileged access controls are enforced, monitored and evidenced. Each step ends with an artifact an assessor can inspect, so the order also serves as a checklist for the assessment file.
Inventory privileged accounts and groups
Start by listing every account and group that grants administrative rights across directories, servers, network devices, cloud tenancies, databases and applications. Include local administrator accounts, break glass accounts, service accounts and any shared privileged logins. The owning team, usually identity and access management with system owners, confirms each entry. This step closes when the organization holds a reviewed privileged account register with an accountable owner and a last-used date for each account, which becomes the baseline for every later control.
Enforce inactivity and revalidation rules
Configure the identity platform so privileged access is disabled after 45 days of inactivity and after 12 months unless a named reviewer revalidates it. Where directories cannot enforce these rules natively, use scheduled reports and a documented disablement procedure. For access that must survive review, a certification campaign in a tool such as midPoint can route each item to a designated reviewer who keeps, changes or revokes it within a set timeframe. This step closes when disablement runs produce logs and each privileged account carries a documented revalidation decision.
Deploy jump servers for administrative activity
Route administrative sessions through hardened jump servers so that administrators do not connect directly from general-purpose workstations to production systems. Restrict who can reach the jump servers, require the privileged account to authenticate there, and record session activity. Network teams confirm that firewall rules block direct administrative paths. This step closes when a network test shows that administrative protocols reach production only through the jump servers and the access rules are documented.
Separate privileged operating environments
Build privileged operating environments that are not virtualised inside unprivileged environments, so an administrator's session cannot be hosted within a user-level desktop or session. Document which platforms run privileged work, how they are patched and how they are isolated from general user activity. Confirm the design with the architecture owner and test it with a representative administrator workflow. This step closes when an architecture record shows the separation and a test confirms that privileged tasks run only in the designated environments.
Vault break glass and service credentials
Move the credentials for break glass accounts, local administrator accounts and service accounts into a managed secrets store. Credentials should be long, unique, unpredictable and rotated under a documented procedure. Where a platform supports it, such as OpenBao with dynamic short-lived credentials and lease-based revocation for database access, prefer dynamic credentials over static ones. Scan code repositories and pipelines for committed secrets, for example with GitLab pipeline secret detection, so hard-coded credentials are found. This step closes when a credential inventory shows each sensitive account stored in the vault and the scan reports show no unresolved committed secrets.
Centralize privileged and account management logs
Forward privileged access events and privileged account and security group management events to a central log platform. Protect those logs from unauthorized modification and deletion, and set up analysis so that events from internet-facing servers and detected cyber security events are reviewed in a timely manner. Where applications keep their own audit logs, such as Nextcloud's admin_audit app writing to audit.log, include them in the forwarding design. This step closes when a test administrative action appears in the central platform with the expected fields, and the protection settings are documented.
Prove incident handling and assemble the evidence file
Confirm that the incident response plan covers privileged access events, that incidents are reported to the CISO and to ASD where required, and that the response plan has been exercised. Then assemble the evidence file: the register, revalidation records, jump server configuration, environment design, vault inventory, secret scan reports and log samples. Ask the independent assessor which evidence format they prefer before finalizing the file. This step closes when each ML2 control has a mapped evidence item, and an internal review confirms the file is complete before assessment begins.
How lifecycle, access paths and logging support one another
An assessor reads the Maturity Level Two privileged access controls together because each one proves little on its own. An account disabled after 45 days of inactivity (ISM-1648) or removed after 12 months without revalidation (ISM-1647) shows that the organization set a limit, but not that the limit held. The same is true of logging: central records of privileged events (ISM-1509, ISM-1650) are only convincing if privileged work actually flowed through the jump servers required by ISM-1387 and did not run inside a virtualised privileged environment that ISM-1687 prohibits. Before the assessment, confirm that the lifecycle records, the jump server session records and the central log sources describe the same population of privileged accounts.
Access certification campaigns, credential vaulting and central logs are the points where that linkage can be demonstrated. A certification campaign run in a tool such as midPoint gives designated reviewers a documented decision on each privileged role assignment, so the review record shows which accounts were kept, changed or revoked and when. A secrets store such as OpenBao can hold the credentials for break glass, local administrator and service accounts (ISM-1685), issue short-lived credentials and revoke them automatically on lease expiry, so the vault audit trail and the lease history can be matched against the review decisions. Confirm with your own environment whether the vault and the directory share an identifier for each account, because an assessor will expect to trace one privileged account from its approval, through its vaulted credential, to its logged activity.
The practical risk is that each record is kept by a different team and no one checks that they agree. A revoked role that still has a live vaulted credential, or a break glass credential used outside an approved incident, will show up only if the review records, vault logs and privileged event logs are compared. Plan a periodic reconciliation that samples privileged accounts across all three sources, and retain the output as evidence. The reconciliation is also where log protection (ISM-1815) becomes relevant, because the comparison is only trustworthy if the records cannot be edited after the fact.
Evidence that passes an ML2 privileged access assessment
An assessor testing privileged access at Maturity Level Two looks for records that show the controls operate over time, not only that they exist on paper. The six artifacts below connect the disabling rules, jump server design, credential handling and central logging, so each one can be traced back to the ISM controls it supports.
Privileged account inventory with last-use dates
A current register of every privileged account, including named administrators, break glass accounts, local administrator accounts and service accounts, with the last date each one authenticated. This is the starting point for ISM-1648, which requires privileged access to be disabled after 45 days of inactivity. Check that the export comes from the directory or identity platform itself, not a spreadsheet, and that accounts with no recorded use are explained rather than silently omitted.
Revalidation and disable records
Records showing that each privileged account was reviewed, revalidated or disabled on schedule, and that the disable actions took effect. ISM-1647 sets the 12-month revalidation limit, so an assessor will sample accounts and ask for the approval date, the approver and the outcome. Access certification campaigns with designated reviewers and recorded decisions produce this evidence directly. Confirm that the reviewer is not the account holder or the person who granted the access.
Jump server configuration and session logs
The configuration showing that administrative activity must pass through jump servers, as ISM-1387 requires, along with session logs tying each privileged session to a named user and target system. Assessors look for direct routes to production that bypass the jump host, so include firewall rules and access control settings that block them. Keep session recordings or command logs for the period the assessor samples, and confirm they cannot be edited by the administrators they record.
Environment separation diagrams
Architecture diagrams and matching configuration showing that privileged operating environments are not virtualised within unprivileged environments, the condition ISM-1687 addresses. The diagram should name the hosts, hypervisors, management networks and the paths administrators use to reach each one. Update the diagram after each infrastructure change, because a stale diagram that omits a new hypervisor is one of the more common findings in this area.
Credential management records for break glass and service accounts
Records showing how break glass, local administrator and service account credentials are generated, stored, rotated and retrieved, measured against ISM-1685's requirements for long, unique, unpredictable and managed credentials. A secrets manager can hold these credentials and issue short-lived leases, with an audit trail of each checkout. Confirm who can retrieve break glass credentials, when that access was last used, and whether each use triggered a review.
Central log samples with protection settings
Sample entries from the central log store for privileged access events and privileged account and security group changes, as ISM-1509 and ISM-1650 require, together with the settings that protect those logs from modification and deletion under ISM-1815. An assessor will ask you to show a specific event, such as a role change, traced from source to central store. Keep the retention configuration, write permissions and integrity controls alongside the samples so the evidence shows the logs are trustworthy.
What meeting ML2 privileged access controls costs
Tooling is the cost most buyers look at first, and it is the one most affected by platform choice. ML2 privileged access controls need a jump server or equivalent access broker, a secrets store for break glass, local administrator and service account credentials, a place to run access reviews, and a central log platform for privileged events. Each of these can be bought as a commercial product with annual licensing, or deployed from open-source software inside your own infrastructure, where the software license itself is typically zero but hosting and support are still yours to pay for.
- Commercial licenses: Per-user, per-node or per-privileged-account fees for PAM, secrets management and SIEM products usually recur every year and scale with the number of administrators and systems.
- Open-source licenses: Components such as OpenBao (MPL-2.0), midPoint (EUPL-1.2+) and Nextcloud (AGPL-3.0-only) carry no per-seat license fee, so the recurring spend shifts to infrastructure and support.
- Infrastructure: Compute, storage and backup for the jump servers, vault cluster and log store are recurring and grow with log volume and retention.
- Support subscriptions: Vendor support for open-source components is optional and recurs if you choose it.
Ask the vendor or partner to separate license fees, infrastructure and support in the quote, and confirm which license terms apply to each component you plan to deploy.
Engineering effort is usually the largest one-time cost. Building jump servers, configuring non-virtualised privileged environments, moving local administrator and service account credentials into a managed store, and wiring privileged events into central logging all require skilled platform and security engineers. The work is front-loaded, but it also reappears when systems change, such as new network segments, new cloud accounts or a new identity provider.
- Jump server build: Hardening, session recording, network paths and access rules for administrative activity, which must go through jump servers under ISM-1387.
- Credential migration: Discovering existing local administrator and service accounts and moving their credentials into managed storage, which is often the slowest step in legacy estates.
- Expiry and revalidation rules: Configuring the 45-day inactivity disable (ISM-1648) and the 12-month revalidation rule (ISM-1647) in identity and directory systems.
- Logging integration: Forwarding privileged access and account management events to a central store and protecting them from modification (ISM-1815).
Cost drops when the estate is standardized and the number of distinct administrative paths is small. It rises with the number of legacy systems, custom authentication and unmanaged accounts. Ask for an estimate broken down by these workstreams and a list of assumptions about system count.
Evidence upkeep is the recurring work of proving the controls keep working. Assessors expect current records, not only a snapshot taken at implementation, so someone must run access reviews, retain logs, review inactive accounts, rotate and check credentials, and record exceptions. This work recurs on each review cycle and is often underestimated because it is spread across security, IT operations and application owners.
- Access certification cycles: Designated reviewers decide whether to keep, change or revoke privileged access items on a set timeframe. midPoint supports this kind of campaign, but reviewers' time is still a recurring internal cost.
- Inactivity and revalidation reports: Regular reports showing disabled accounts and accounts awaiting revalidation.
- Log review and retention: Reviewing privileged event logs and keeping them for the period your assessment requires (ISM-1906 and ISM-1228 address timely analysis).
- Incident evidence: Records showing incidents were reported to the CISO and enacted under the incident response plan (ISM-0123, ISM-0140, ISM-1819).
To control this cost, automate report generation and keep evidence in a single location. Ask any partner how evidence is collected, who maintains it after handover and how many hours per cycle they expect your team to spend.
External review covers two different activities that buyers often confuse. A consultant or implementation partner can review your design and prepare evidence before an assessment, which is advisory work you pay for directly. An independent assessor or auditor then tests the controls and issues any formal conclusion, and their fees depend on scope, sampling and the assessment type. DeployOpen prepares systems, controls and evidence for assessment but does not issue reports or certifications.
- Pre-assessment readiness review: A one-time external check of design and evidence, priced from the agreed written scope.
- Assessor fees: Charged by the independent assessor for testing, typically based on the size of the environment and the number of samples they select.
- Sampling effort: Auditors select privileged accounts, review events and ask for supporting records. Larger estates and more administrative paths mean more samples.
- Re-testing: Repeat testing after findings or after a change in scope recurs as a cost.
Ask the assessor how they plan to sample privileged accounts and events, what evidence they will request in advance and what they count as in scope. Those answers shape the assessment fee more than the tooling choice does.
Open-source tools that support ML2 privileged access evidence
This table compares four open-source tools against the ML2 privileged access controls they can help evidence. Each row names the tool, its license, the control area it supports and what must be configured before an assessor would accept the output. A tool produces records, but the organization still has to prove that its privileged access process works as described.
| Tool and license | ML2 control area | What it can produce | Configuration and evidence still required |
|---|---|---|---|
| OpenBao (MPL-2.0) | Credentials for break glass, local administrator and service accounts (ISM-1685) | Encrypted secret storage, dynamic short-lived credentials and leases that revoke secrets automatically on expiry | Confirm which privileged credentials are moved into OpenBao, set lease durations, and retain revocation and access logs as evidence |
| midPoint (EUPL-1.2+) | Privileged access reviews and deactivation after inactivity or 12 months without revalidation (ISM-1648, ISM-1647) | Access certification campaigns where designated reviewers decide within a set timeframe whether to keep, change or revoke access | Define campaign schedules and deadlines, assign reviewers, record decisions and show that revoked access was removed from target systems |
| GitLab Community Edition (MIT) | Protection of credentials that must never sit in code (ISM-1685) | Pipeline secret detection on committed and pushed files, with results in a gl-secret-detection-report.json job artifact in every tier | Enable the scanning job on every repository in scope, decide how findings are triaged and rotated, and keep reports as evidence of the scan cadence |
| Nextcloud admin_audit app (AGPL-3.0-only) | Central logging of privileged events (ISM-1509, ISM-1650) | Additional administrative event details written to audit.log in the data directory or to a path set with logfile_audit | Enable the app, route the log to a protected store, forward it to central logging, and confirm that the log cannot be edited or deleted by administrators |
| All four tools together | Evidence for ML2 privileged access as a set | Records from each tool that an assessor can sample | Tools do not satisfy the controls by installation. The organization must document the process, configure each tool and test that the evidence matches the stated control |
Who owns, implements and assesses ML2 privileged access
Your organization remains accountable for every privileged access control at Maturity Level Two, whether a partner builds it or not. Ownership covers the decisions that define who may hold privilege, how long access lasts, and what happens when someone leaves or changes role. These decisions must be written down and approved by the people responsible for security risk, because an assessor will ask who made them and when.
- Account policy: Set the inactivity limit and the revalidation cycle for privileged accounts, and document why those values were chosen.
- Access decisions: Approve each privileged role, name the business owner of each break glass and service account, and record the approval.
- Access reviews: Run periodic certification of privileged assignments and act on the results, including revocations.
- Incident response: Own the plan for reporting privileged-access incidents to the CISO and to ASD, and rehearse it.
- Operating records: Keep the logs, tickets and sign-offs that show the controls ran in practice, not only on paper.
Before engaging anyone, confirm that a named executive owns each of these items and that the policy text matches what the systems actually enforce.
An implementation partner can build and configure the technical controls that ML2 expects, then hand over working systems and documentation. This work is usually fixed-scope, with deliverables and timelines agreed in writing before it starts. The partner prepares the controls and evidence, but the organization accepts them and operates them after handover.
- Jump servers: Build the administrative access path so that privileged activity runs through controlled hosts rather than workstations.
- Credential vaulting: Store break glass, local administrator and service account credentials in a managed vault with rotation and access logging.
- Central logging: Forward privileged access and account management events to a protected log store, and configure retention and integrity protection.
- Evidence packs: Document configuration, test results and screenshots or exports that map each control to its ISM identifier.
- Handover and training: Transfer runbooks so your staff can operate the controls without the partner present.
Ask the partner which of these items they will deliver as configuration, which as documentation, and what they will not touch.
An independent auditor, assessor or certification body tests whether the controls work and reports on them. The Essential Eight is a set of mitigations, not a certification scheme, so there is no ASD certificate. Assessment of maturity is performed against the maturity model and the relevant ISM controls, and the assessor's findings belong to the assessor and to the organization that commissioned the work.
- Design and operation testing: The assessor samples privileged accounts, checks inactivity disabling and revalidation records, and traces logged events back to source.
- Evidence sufficiency: The assessor decides whether the evidence supports each control, which is why partner-prepared material is only one input.
- Independence limits: A partner that designed or configured a control generally cannot also test it and sign off its effectiveness.
- Reporting: Only the assessor issues the assessment report or opinion that the organization may share with customers or regulators.
- Scope agreement: Confirm in writing with the assessor which ISM controls and which maturity level are in scope before testing begins.
Check whether your customers or regulators accept a self-assessment, a partner's readiness review, or only an independent report.
Where ML2 privileged access programs usually fall short
Most organizations that claim Maturity Level Two for restrict administrative privileges have the policy in place but leak at the edges. The gaps below cluster around accounts that fall outside the rules, reviews that leave no trace, and logs that administrators can change. Each card names the check to run and the action to close it.
Service accounts outside inactivity rules
Inactivity and revalidation rules are often written for people, so service accounts, local administrator accounts and scheduled task identities keep working long after their owners have gone. ML2 expects privileged access to be disabled after 45 days of inactivity and removed after 12 months unless revalidated, so these accounts must be in scope too. Action: export every account with privileged rights from directory, local and application systems, tag each as human or non-human, and apply the same expiry logic to both.
Revalidation without records
Many teams state that privileged access is revalidated each year but cannot show who approved which grant, when, or what changed as a result. An assessor will ask for the decision record, not the intent. Access certification campaigns with named reviewers and a deadline for each decision produce that record. Action: run a dated review campaign, capture keep, change or revoke decisions with reviewer names, and retain the outcome as evidence.
Jump servers bypassed by direct paths
A jump server only protects administration if it is the sole route. Teams often leave direct remote desktop, SSH or management console paths open for speed or troubleshooting, which makes the jump server a suggestion. ML2 requires administrative activity to go through jump servers. Action: trace every management path with network flow data and firewall rules, then block direct administrative ports from user and admin networks except through the jump tier.
Admin virtual machines inside user desktops
Some organizations run an administrative virtual machine on a standard employee laptop or desktop to keep admin work separate. The host is still an unprivileged environment that a compromised user session can reach. ML2 does not allow privileged operating environments to be virtualised within unprivileged environments. Action: confirm where each privileged session originates, and move administrative workloads to hosts that users cannot administer or browse from.
Break glass credentials shared or stale
Emergency accounts are often written into a shared password vault that dozens of staff can open, or left unchanged since installation. ML2 requires break glass, local administrator and service account credentials to be long, unique, unpredictable and managed. A shared or never-rotated secret means no one can attribute use of it. Action: assign each emergency credential a unique value, store it in a controlled secrets manager with access logging, and rotate it after every use and on a set schedule.
Privileged logs alterable by admins
Central logging of privileged events is only useful if administrators cannot edit or delete the records of their own actions. Logs kept on the administered server, or in a store that the same admin group controls, fail this test. ML2 requires privileged access and account management events to be centrally logged, and event logs protected from unauthorised modification and deletion. Action: forward privileged events to a separate log store with restricted write access, and test that an administrator cannot remove entries from it.
Questions buyers ask about ML2 privileged access
How much effort does Maturity Level Two privileged access take?
Effort depends mainly on how many privileged accounts, admin paths and systems sit in scope, and how much of today's access is undocumented. ML2 adds controls on top of ML1: inactive privileged access must be disabled after 45 days, privileged access must be revalidated at least every 12 months, administrative activity must pass through jump servers, and privileged events must be centrally logged. Each of these needs a configured system, a documented process and recurring evidence. Organizations with a clean directory and existing logging usually face less work than those discovering shadow admin accounts for the first time. Ask any partner to size the work from your own inventory, not from a generic template.
Can we implement Maturity Level Two privileged access in-house?
Yes, if your team has the skills and capacity to configure identity, logging and access tooling and to run the recurring reviews. The work is largely engineering and process: building jump server paths, rotating and vaulting break glass and service account credentials, setting inactivity rules, and wiring privileged events into a central log store. Many teams split the work, keeping ownership of the control and its decisions in-house while bringing in outside help for platform design, hardening or a readiness review. Whichever route you choose, the organization remains responsible for its controls.
What skills and roles does the work need from our team?
At minimum you need people who own the identity directory and privileged role assignments, engineers who can run jump servers and secrets management, a logging owner who can protect and analyze event logs, and a control owner who can produce evidence for an assessor. Reviewers from business units are needed for access revalidation. Security leadership must handle incident reporting to the CISO and, where relevant, to ASD, and keep the incident response plan current. A single engineer rarely covers all of these roles, so ask a partner how it will hand skills over to your staff.
How long does preparation for Maturity Level Two usually take?
No duration is fixed by ASD for this step, so treat any single number with caution. Preparation length is driven by the size of the privileged estate, the state of current logging, change windows for production systems, and how many revalidation cycles you need before evidence is consistent. Ask for a timeline built from a written scope that names the systems, accounts and log sources included. Confirm with your own assessor which evidence window they expect, because a control that has operated for a short period may be judged differently from one with a longer track record.
Does ASD certify Maturity Level Two privileged access?
No. The Essential Eight is a set of mitigations rather than a certification scheme, and ASD does not issue a certificate for any maturity level. Maturity is shown through an assessment of how each strategy is implemented and how effectively it works against the maturity model. Your organization owns the outcome, and an independent assessor reaches the conclusion. Implementation partners can prepare systems, settings and evidence, but they do not issue assessment reports. Check the current ASD guidance before you commit to a level, since your contracts or regulators may ask for specific documentation.
What should we ask a partner to include in a written quote?
A useful quote names the scope before the price. Ask for the list of privileged account types, directories, jump paths, secrets stores and log sources in scope, plus the systems excluded. Request the deliverables, such as configured jump servers, inactivity and revalidation procedures, central logging configuration and an evidence pack mapped to the ISM controls for ML2. Ask which tasks are one-time and which recur, such as quarterly revalidation and log review, and who performs each. Confirm what the partner will not do, including issuing audit reports, and how knowledge transfer to your team will be handled.
Which parts of Maturity Level Two can be outsourced?
Configuration, platform hardening, log pipeline setup and evidence preparation can be outsourced to an implementation partner under a fixed scope. Ongoing operation, such as running access revalidation campaigns or reviewing privileged events, is often kept in-house or put under a support retainer. Decisions about which access is justified, and incident reporting obligations, stay with your organization. Make the split explicit in the contract so that no recurring task falls between two parties.
How DeployOpen scopes ML2 privileged access work
A DeployOpen engagement for Maturity Level Two privileged access starts with a written, fixed scope that names the systems, environments and accounts in play before any work begins. The first deliverable is an inventory: every privileged account (including break glass, local administrator and service accounts), every administrative path into production, and every environment where privileged operations run today. That inventory shows which controls already exist, which are partial, and which are missing. Organizations should expect the scope to list the ML2 controls it covers, such as the inactivity and revalidation rules, jump server routing, the non-virtualised privileged environment requirement, and central logging of privileged events, so that the boundary of the work is explicit in the contract.
The build follows the inventory. DeployOpen can stand up or harden a jump server path so that administrative activity goes through it, configure a secrets store such as OpenBao for storing long, unique credentials for break glass and service accounts, and wire privileged account and group changes into a central log. Access review workflows, where a tool such as midPoint runs certification campaigns, can be scoped in the same engagement if the client wants recurring reviewer decisions evidenced. Each component is delivered inside the client's own infrastructure, and the written scope should state who holds the administrative credentials at handover and where the audit logs are stored.
Evidence preparation is the last deliverable. DeployOpen collects configuration exports, log samples, review records and procedure documents mapped to each ML2 control so that an independent assessor can test them. DeployOpen prepares systems and evidence only. It does not issue assessment reports, attestations or certifications, and the organization owns its controls and the decision to claim a maturity level. Before signing, ask the provider to confirm in writing which evidence will be delivered, who will walk the assessor through it, and what happens if the assessor requests additional samples. Confirm the assessor relationship with your own assurance function or the body that will perform the assessment.
How DeployOpen prepares ML2 privileged access evidence
DeployOpen works on the Maturity Level Two privileged access requirements inside your own infrastructure, from scoping through handover. We prepare systems, logs and records so your organization can show how automatic disabling, jump servers, break glass credentials and central logging operate, while the organization keeps ownership of its controls.
How we scope
- Engagements are fixed-scope, with the privileged access systems, accounts and environments in scope agreed in writing before work starts.
- The written scope lists which ML2 privileged access controls are covered, such as inactivity disabling, revalidation and jump server routing.
- We confirm with your team which administrative accounts, service accounts and break glass credentials exist before any change is planned.
How we build
- We configure account lifecycle rules so privileged access is disabled after 45 days of inactivity and after 12 months without revalidation.
- We set up jump servers and separate privileged environments, and document how administrative activity is routed through them.
- We deploy central logging for privileged access and account management events, with protected log storage and timely analysis.
How we hand over
- Each control is documented with its configuration, owner, evidence location and the test steps an assessor would be expected to follow.
- We deliver a mapping from each ML2 privileged access control to the system settings and log records that support it.
- Your team receives operating runbooks for access reviews, break glass use and credential rotation, so the controls keep running after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Retainers can cover recurring revalidation campaigns, log review checks and changes to privileged access as your environment evolves.
- An independent auditor or assessor reviews the evidence and issues any report, since DeployOpen prepares evidence but does not certify it.
