What the Essential Eight restrict administrative privileges strategy asks for
The restrict administrative privileges strategy asks you to control who holds admin rights, how those rights are requested and used, and how long they last, and each of those expectations maps to controls in the Information Security Manual. A bastion such as Teleport or JumpServer can enforce and record much of this, but it cannot satisfy the strategy alone, because approvals, account design and periodic review remain organizational work. The Essential Eight is a set of mitigation strategies rather than a certification scheme, so there is no ASD certificate to obtain. Maturity is instead evidenced by assessing how each strategy is implemented and whether it works against the maturity model's requirements, which is what your assessor or internal reviewer will test.
The maturity levels are reflected in the ISM Essential Eight baseline profiles. In ISM v2026.09.4 (September 2026), the ML1, ML2 and ML3 profiles contain 46, 87 and 123 ISM controls respectively, and every ML1 control also appears at ML2. For privileged access, the ML1 set includes requirements to validate privileged access requests when first made (ISM-1507) and to give privileged human users a dedicated account used only for privileged duties (ISM-0445). Privileged accounts must also be kept away from internet, email and web services unless explicitly authorised (ISM-1175, ISM-1883). At ML2, the set adds disabling privileged access after 45 days of inactivity (ISM-1648) and after 12 months unless revalidated (ISM-1647), plus routing administrative activity through jump servers (ISM-1387).
Start by mapping each control ID to a concrete owner, procedure and evidence source, then check which ones your bastion configuration covers. Confirm with your assessor and the ISM OSCAL catalog which control IDs apply to your target maturity level and system scope, since the profiles are the authoritative list. Gaps in approval records, inactivity reviews and dedicated account governance are usually process gaps, not software gaps, so plan those workstreams alongside the platform build.
Mapping ISM privileged access controls to bastion configuration
This table maps the ISM privileged access controls tagged to Essential Eight maturity levels one and two to what the control asks for and how a Teleport or JumpServer bastion can be configured to meet it. Read each row as a starting design point, then confirm the exact control wording in the ISM OSCAL catalog before you write it into a system security plan. The main takeaway is that most of these controls are satisfied by configuration of the bastion and its identity source, but the evidence an assessor expects still has to be produced and kept.
| Control and intent | What the bastion must do | How to configure it in Teleport or JumpServer |
|---|---|---|
| ISM-1507 (ML1): validate privileged access requests when first requested | Confirm the requester is entitled to the privileged role before access is granted, with a recorded approver. | Teleport: use just-in-time access requests and reviews (Enterprise). JumpServer: use ticket and just-in-time approval workflows (Enterprise). Confirm which of these your edition includes before design. |
| ISM-0445 (ML1): dedicated privileged account used only for privileged duties | Separate admin identities from everyday user identities, and block privileged roles from being assigned to daily-use accounts. | Create a separate admin identity in the identity provider and map only that identity to privileged roles. Use distinct role names and restrict role assignment through the identity provider group mapping. |
| ISM-1175 (ML1): no internet, email or web use from privileged accounts unless authorized | Stop privileged sessions from browsing the web, reading email or reaching internet resources, unless a documented exception exists. | Limit privileged roles to server, database and Kubernetes targets only. Do not grant web application access to admin roles. Confirm any web-based connector is excluded from privileged role scope and test with a sample admin account. |
| ISM-1883 (ML1): authorized internet, email and web access strictly limited to duties | Where an exception is approved, the access must be narrow and tied to a specific task. | Use separate, time-limited roles for any approved exception, with a short session duration and a named approver. Record the exception in the access request so it can be sampled later. |
| ISM-1380 (ML1): privileged access controls as set out in the catalog (confirm exact scope) | Apply the privileged access controls the catalog ties to this identifier to the bastion and its connected resources. Confirm the exact requirement text first. | Route privileged sessions through the bastion and disable direct login paths to target systems. Confirm the exact wording and applicability in the ISM OSCAL catalog before mapping it to a configuration item. |
| ISM-1648 (ML2): disable privileged access after 45 days of inactivity | Remove or lock privileged access that has not been used for 45 days. | Teleport: use short-lived certificates and access list or role expiry, with review of idle users in access reviews (Enterprise). JumpServer: disable or lock inactive accounts through the identity source and confirm the inactivity logic in the edition you run. |
| ISM-1647 (ML2): revalidate privileged access every 12 months | Confirm each privileged entitlement is still needed at least every 12 months, or remove it. | Schedule access reviews for each privileged role and retain the reviewer's decision. Use access lists with a defined review period in Teleport Enterprise, or a recurring review workflow in JumpServer, and confirm the review feature in your edition. |
| ISM-1687 (ML2): no privileged operating environments inside unprivileged virtualized environments | Keep privileged administration workstations and hosts separate from unprivileged virtual environments. | Place the bastion and its administration hosts on dedicated infrastructure. Document the hosting design and confirm with the platform team that privileged admin VMs do not run inside user desktop or general virtualization pools. |
| ISM-1387 (ML2): administrative activity routed through jump servers | Ensure administrative sessions reach target systems only through the jump server, not directly from user workstations. | Teleport: make the proxy the only path to SSH, Kubernetes and database targets, and remove direct SSH keys. JumpServer: restrict target network reachability so only the bastion can reach managed assets, and block direct admin sessions at the firewall. |
How ML1, ML2 and ML3 change the bastion design
At Maturity Level One, the access layer must separate privileged work from everyday work. The ISM controls tagged to ML1 ask that privileged requests be validated when first made, that privileged human users have a dedicated privileged account used only for privileged duties, and that privileged accounts cannot reach the internet, email and web services unless explicitly authorised. Authorised exceptions must be narrow.
- Dedicated admin identities: Each administrator gets a separate account, such as an admin identity in the directory, used only through the bastion for privileged tasks.
- Validated requests: The bastion's role or access request path should record who asked for privileged access, who validated it and when, before the session starts.
- Separation from browsing and mail: Block the privileged account from outbound web, email and general internet access at the network and endpoint layers, not only in policy.
- Scoped exceptions: Any authorised web or mail use should be listed, limited to the duties that require it and reviewed.
Confirm with your ASD assessor or the ISM OSCAL catalog which ML1 control wording applies to your environment before you fix the account model.
Maturity Level Two keeps every ML1 control and adds controls that act on time and path. The ML2 additions tagged in the ISM OSCAL profile require privileged access to be disabled after 45 days of inactivity and after 12 months unless revalidated, require administrative activity to go through jump servers, and prohibit privileged operating environments from being virtualised within unprivileged environments.
- Inactivity expiry: Configure the identity source or bastion so privileged accounts lapse after the inactivity period, with a report that proves it ran.
- Revalidation cycle: Schedule a recertification of every privileged grant at the 12 month point, and remove grants that are not renewed.
- Mandatory jump server: Route all administrative sessions to servers and databases through the bastion, and close direct SSH and RDP paths from admin workstations.
- No nested privileged virtualisation: Keep privileged operating environments out of unprivileged virtual machines, and document the hypervisor and admin workstation build that supports this.
Ask your implementation partner to show how the bastion, the directory and the network rules each enforce these three ML2 points.
Maturity Level Three builds on ML2 and is where most of the ML2 controls reappear. In the ISM v2026.09.4 Essential Eight profiles, all ML2 controls except ISM-1691, ISM-1695 and ISM-1873 are also in ML3, and those three are replaced by stricter versions. The practical design effect is that a bastion built to ML2 is the starting point, not the finish line.
- Replaced controls: Treat ISM-1691, ISM-1695 and ISM-1873 as open items until you read the current ML3 wording and map it to your configuration.
- Stricter versions: Expect tighter expectations on the controls the ML3 profile replaces, so review account lifetimes, exception handling and admin paths against the new text.
- Evidence depth: Plan for session logs, approval records and expiry reports to be sampled, not just shown once.
- Change control: Record each change to the bastion's roles and policies so the configuration matches the level claimed.
Before design sign-off, read the current ISM OSCAL ML3 profile and confirm the exact wording of the three replaced controls with ASD guidance or your assessor.
Which open source platforms fit this strategy
Restrict administrative privileges under the Essential Eight comes down to three things: a gateway that controls and records admin sessions, an identity source that enforces strong authentication, and a clear rule for when elevated access is granted. The platforms below cover different parts of that chain, and the edition and licensing choices shape which one fits your organization.
Teleport for certificate-based access
Teleport issues short-lived certificates instead of relying on shared SSH keys or Kubernetes tokens, which maps directly to the need for dedicated, individually attributable privileged accounts. It also records sessions with playback in both editions. The Community Edition is limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so confirm your size against that threshold before planning. Just-in-time access requests and moderated sessions are Enterprise features.
JumpServer as a PAM bastion
JumpServer is an open source PAM platform and bastion host covering SSH, RDP, Kubernetes, databases and web access from one workspace. It is licensed under GPL-3.0 and its Community edition is free for self-hosted deployments up to 5,000 assets in a standalone topology. Ticket and just-in-time approval workflows, password rotation and custom roles are Enterprise features, so check which approval steps your Essential Eight evidence depends on before choosing a tier.
Apache Guacamole as a browser gateway
Guacamole provides browser-based RDP and SSH access without client software, which suits administrators working from managed or restricted workstations. It can place a recording and access point in front of Windows and Linux servers that have no native bastion support. Confirm the current session recording, approval and identity integration features against the project documentation and your own test deployment, since these vary by build and configuration.
Keycloak for MFA and single sign-on
Keycloak can act as the identity source for the bastion, enforcing multi-factor authentication for every privileged login and mapping groups to privileged roles. It supports OpenID Connect, SAML 2.0 and LDAP or Active Directory federation. Strong authentication for administrators depends on how the gateway and Keycloak are configured together, so test MFA enforcement on every privileged path, including break-glass accounts, before treating it as a control.
How to roll out dedicated admin accounts and a bastion
The sequence moves from knowing which privileged accounts and systems exist to a bastion where every administrative session is tied to a named identity, MFA, a recording and a documented review. The end result is evidence an assessor can sample against the Essential Eight restrict administrative privileges controls.
Inventory privileged accounts and systems
Start by listing every system where administrative rights exist: servers, databases, Kubernetes clusters, network devices, hypervisors and cloud consoles. For each one, record who holds privileged rights, whether the access is human or service, and which accounts are shared. The security team and system owners do this together, because owners know which accounts exist outside the directory. The step is done when the list is reviewed by each system owner and every privileged account has a named owner and a justification for its rights.
Separate admin identities from daily accounts
Create a dedicated privileged account for each administrator, used only for privileged duties, and keep the everyday account for email, web and documents. The privileged account should not be able to browse the internet, read email or open web services unless that access has been explicitly authorized. Identity administrators and the security team own this change, and access requests for each new privileged identity should be validated when first requested. The step is done when every privileged human user has exactly one dedicated admin identity and the authorization record for it.
Route administrative activity through the bastion
Move administrative connections so that they pass through the jump server, whether that is Teleport, JumpServer or another gateway you select. Remove direct paths from administrator workstations to the protected systems at the network layer, and retire shared SSH keys or standing root credentials where the bastion can issue short-lived access instead. Platform engineers configure the connectors, while network teams confirm that firewall rules permit only the bastion. The step is done when a test administrator cannot reach a protected system except through the gateway, and the firewall rules that prove it are documented.
Enforce MFA and turn on session recording
Require multi-factor authentication at the bastion for every privileged session, and connect the bastion to your identity provider so that identity, group membership and MFA status come from one source. Enable session recording for SSH, RDP, Kubernetes and database protocols that you have brought under the gateway, and confirm where recordings are stored and who can read them. Check that the recording settings are on for each connector, not only for the most common ones. The step is done when a sample of sessions shows an authenticated identity, an MFA event and a recording for each protocol in scope.
Apply inactivity and revalidation rules
Configure the bastion and identity directory so that privileged access is disabled after a period of inactivity and must be revalidated at a set interval. The Essential Eight alignment for these rules is set by the ISM controls for maturity Level Two, so confirm the exact thresholds with your assessor and record them in the access policy. Access owners review each privileged identity at the revalidation point and remove rights that are no longer needed. The step is done when disabled and revalidated accounts are visible in a report and the review decisions are signed off.
Gather evidence for assessment
Assemble the artifacts an assessor will sample: the privileged account inventory, the authorization and validation records, the bastion configuration, firewall rules showing the gateway as the only path, MFA and recording settings, inactivity and revalidation records, and a sample of recorded sessions with their approvals. Map each artifact to the ISM control IDs for the maturity level you target, so the evidence is organized by control rather than by tool. Confirm with your assessor which evidence format and sampling approach they expect. The step is done when each in-scope control has a named evidence source that someone other than the builder can retrieve.
Evidence assessors ask for under restrict administrative privileges
This table lists the records an assessor is likely to request for the restrict administrative privileges strategy and which component usually produces each one. Read it as a starting inventory: confirm with your assessor which items they want, in what format, and for which systems, because the evidence set depends on your scope and maturity target.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Privileged account register | Every privileged account, its owner, its purpose and that it is used only for privileged duties (ISM-0445) | Identity provider for account records, with Teleport or JumpServer role mappings for access scope |
| Validation records for access requests | That each request for privileged access was validated when first made (ISM-1507), with the approver and the decision | JumpServer ticket workflows or Teleport access requests on Enterprise, with the identity provider as source |
| Approval and just-in-time logs | Time-limited elevation granted, who approved it, and when it expired | Teleport Enterprise just-in-time access or JumpServer approval workflows, confirmed against your edition |
| Session recordings and retention | What privileged users did on servers, databases and clusters, and how long recordings are kept | Teleport or JumpServer session recording, with storage location and retention settings confirmed by you |
| Inactivity and revalidation reports | Privileged accounts disabled after 45 days of inactivity (ISM-1648) and revalidated within 12 months (ISM-1647) | Identity provider lifecycle reports, combined with bastion last-login data |
| Privileged accounts barred from internet, email and web use | Which privileged accounts are blocked from internet, email and web services and which exceptions are authorised (ISM-1175, ISM-1883) | Network and endpoint policy records, with the bastion access list as supporting evidence |
| Jump server access logs | That administrative activity went through the jump server (ISM-1387) rather than direct connections | Teleport or JumpServer audit logs, forwarded to the SIEM for retention and search |
| Assessment evidence guide mapping | How your controls map to the ISM and Essential Eight references in the assessment evidence guide for enterprise IT | Compliance documentation prepared by you or your implementation partner, not produced by a tool |
What tooling alone does not satisfy
A PAM platform enforces access rules, but the Essential Eight restrict administrative privileges strategy is assessed on how those rules run in daily operations. The cards below cover the decisions, policies and evidence that sit outside the software and that an assessor will test.
Request validation is a process decision
ISM-1507 expects access requests for privileged resources to be validated when first requested. A bastion can hold an approval step, but it cannot decide who is a legitimate approver or what evidence justifies the request. Confirm who signs off each request type, what they check, and whether that rule is written down before the platform is configured.
Dedicated account policy needs HR and identity governance
ISM-0445 requires privileged human users to have a dedicated privileged account used only for privileged duties. Someone must decide who qualifies, retire accounts when roles change, and remove access when people leave. Those decisions sit with HR and identity governance, so the bastion only enforces what the directory already says.
Edition limits may remove approval features
Some approval and just-in-time features are paid or limited by edition. For example, JumpServer lists ticket and just-in-time approval workflows as Enterprise features, and Teleport limits just-in-time requests and moderated sessions to Enterprise. Confirm which controls the chosen edition provides before writing the access procedure, because a missing feature can leave a manual gap.
Session recordings alone do not prove review
A recorded session shows what happened, not that anyone checked it. ML2 and ML3 expectations around privileged activity depend on someone reviewing logs for unexpected use, and that review needs a schedule, an owner and a record of findings. Ask who reads recordings, how often, and how exceptions are escalated.
Vendor access needs its own process
ISM-1387 requires administrative activity to go through jump servers, but vendor staff often arrive with their own identities, devices and urgency. Contracts, support tickets and time-limited approvals must match what the bastion allows. Without that process, vendor sessions become the most common exception to the rule.
Maturity is assessed by people
The Essential Eight is a set of mitigations, not a certification, and maturity is judged through assessment of each strategy's implementation and effectiveness. A product can produce logs and configuration exports, but an assessor will ask who owns the strategy, how it is tested and how gaps are tracked. Plan that evidence and ownership as part of the rollout.
Questions buyers ask before hiring help with Essential Eight privileged access
What drives the cost of an open source PAM project for Essential Eight?
The cost depends on how many systems need to sit behind the bastion, how deeply the platform must connect to your identity provider, which edition you need, and how much session recording storage you must keep. Planning and design, identity integration, gateway hosting, rollout per system, and handover documentation are the main services. Software licenses for the open-source Community builds are typically zero, but Enterprise editions carry license fees that are quoted by the vendor. Recording storage and the gateway infrastructure recur every year, while design and rollout are one-time effort. Ask any partner, DeployOpen included, for a written scope that lists systems, protocols, identity sources, edition, storage retention and handover items, so the quote can be compared line by line.
Can our team deploy a PAM bastion for Essential Eight without outside help?
Yes, a capable platform or security team can deploy a bastion without a partner, provided it has time, Linux administration skills and someone who owns the access policy. The harder parts are usually not the install: they are agreeing which accounts become dedicated privileged identities, wiring approvals and recording into a repeatable process, and producing evidence that an assessor can sample. Teams that run this in-house often underestimate ongoing work such as offboarding, recording review and upgrades. A partner can take over the build and documentation while your staff keep ownership of policy. Decide early which part you will own after go-live.
How long does an Essential Eight privileged access rollout take?
The duration depends on scope, meaning the number of protocols, systems, identity sources, approval paths and the number of people who will change how they log in. Engagements are fixed-scope at DeployOpen, so the timeline, deliverables and acceptance steps are agreed in writing before work starts. A typical pattern is a short design phase, a pilot on a small set of systems, then staged onboarding by system group. Ask for a phased plan with named milestones, the owner of each dependency, and the change freeze windows that apply to your production systems. Any timeline quoted without a stated scope should be treated with caution.
What do we need to provide during a privileged access implementation?
The work needs three groups of people. System owners confirm which servers, databases and Kubernetes clusters are in scope, which accounts are used today, and which maintenance windows apply. The identity team provides the directory or identity provider, group structure, MFA method and the process for creating dedicated admin accounts. Approvers, usually the system owner or a security lead, must agree who can request elevated access, how long sessions may last and who reviews recordings. Without named people in each group, rollouts stall at the access-policy stage. Ask for a responsibilities matrix before signing the scope.
Is Teleport Community Edition enough for Essential Eight privileged access?
Teleport Community Edition may not be suitable for every organization because its distributed builds are licensed only for organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Its feature matrix limits single sign-on to GitHub and keeps just-in-time access requests and reviews in Enterprise. Moderated sessions and dual authorization are also Enterprise features. JumpServer Community edition has its own limits, including that Oracle and SQL Server access, ticket and just-in-time approval workflows, and SSO are listed as Enterprise features. Confirm the license terms and feature list against your employee count, revenue and approval needs before choosing an edition.
Does a bastion alone meet maturity level two for restricting administrative privileges?
No, a bastion alone does not meet the restrict administrative privileges strategy at maturity level two. The Essential Eight is a set of mitigations assessed by implementation and effectiveness, and it asks for more than a gateway. The ISM Essential Eight profiles include controls on validating privileged access requests, dedicated privileged accounts, disabling inactive privileged accounts after 45 days, revalidating access within 12 months, keeping privileged environments separate from unprivileged ones, and routing administrative activity through jump servers. The bastion supports the jump server and recording requirements, while account lifecycle, approvals and review remain process and identity work. Use the ISM OSCAL profiles as your control checklist.
What does DeployOpen not do for Essential Eight assessments?
DeployOpen does not perform Essential Eight assessments, issue audit reports, attestations or certifications, and it does not award maturity levels. The Essential Eight has no ASD certificate, so the maturity level is established through an independent assessment of how each strategy is implemented and how effectively it works. DeployOpen plans, implements, configures, documents and hardens the privileged access platform and prepares the systems, controls and evidence that an assessor will examine, such as access lists, approval records and session logs. Ask any partner to state in writing which parts of the work are implementation and which are assessment, and who will perform the assessment.
What should the quote for an Essential Eight PAM project include?
A useful quote lists each system and protocol in scope, the identity sources and MFA method, the edition and any Enterprise features, the recording retention period and storage location, the approval workflows, and the handover documents. It should also separate one-time work such as design, integration and rollout from recurring items such as hosting, storage, upgrades and support retainers. Ask what is excluded, how changes to scope are priced, and what acceptance tests close each phase. Fixed-scope agreements make these items easier to compare across vendors.
How this maps to the wider privileged access program
Restrict administrative privileges does not stand alone. The strategy depends on multi-factor authentication for every privileged login, on identity governance to decide who holds a privileged account and when that right ends, and on logging to show what those accounts did. Treat the bastion as one control in that chain. ISM-1387 requires administrative activities to go through jump servers, but a jump server that accepts shared credentials or has no owner review of its access list will not satisfy the intent of the strategy on its own. Confirm with your identity team which directory is the source of truth for privileged accounts, how MFA is enforced at the gateway (not only at the desktop), and who approves a grant and who removes it.
Logging is where the strategy is most often tested. Session recordings from the bastion, administrator activity on servers and directory change events should land in the same place, with retention set by your own policy and not by the default of the tool. Decide early which logs go to your SIEM and how long they are kept, and confirm whether your chosen platform records the session content, the commands, or both, and whether recordings can be searched and exported. The Essential Eight evidence should not be assessed in isolation. Read the Essential Eight controls alongside the Information Security Manual (ISM) baseline profiles and the Assessment evidence guide for enterprise IT, which cross-reference the Essential Eight and point to the controls an assessor will sample.
For the next read, use the Essential Eight maturity model on cyber.gov.au to confirm the exact requirements at the maturity level you are targeting. Then check each requirement against the mapping in your own environment: which systems hold privileged accounts outside the bastion, which vendors hold standing access, and where the ISM controls for privileged accounts are already covered by another strategy. Gaps found at this stage are cheaper to close before the assessment than during it.
How DeployOpen scopes and delivers Essential Eight privileged access
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the bastion, its recordings and its logs stay under the client's control. For Essential Eight privileged access, we start from the ISM controls that the client's target maturity level requires and build the access layer to produce evidence against them.
How we scope
- Confirm the target Essential Eight maturity level and the ISM controls in its baseline profile that apply to your systems
- List the administrative paths in scope, including servers, databases, Kubernetes and vendor access, with the owner of each
- Agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope
How we build
- Deploy the chosen bastion, such as Teleport or JumpServer, in your cloud accounts, data center or enclave
- Connect identity sources and MFA, and configure dedicated privileged accounts used only for privileged duties
- Test access requests, approvals, session recording and the removal of standing privileges against the agreed scope
How we hand over
- Document the access model, role catalog, approval steps and break-glass procedure for your operations team
- Provide control-to-evidence mapping showing which configuration, log or report supports each in-scope ISM control
- Train administrators and reviewers on requesting access, reviewing recordings and reporting exceptions
How we support
- Offer ongoing support, upgrades and periodic access reviews through a retainer agreed in writing
- Keep the bastion patched and back up its configuration and session recordings on a schedule you approve
- Prepare the access evidence your internal or independent assessor will ask for, without issuing any certification
