What ISO 27001 privileged access rights require from your PAM platform
A security or compliance lead preparing for a surveillance or recertification audit usually finds the same two gaps: admin accounts shared across a team, and vendor access that nobody can list. Annex A control 8.2, Privileged access rights, asks that the allocation and use of privileged access rights are restricted and managed, so that only authorized users, software components and services receive them. Control 8.18, *Use of privileged utility programs*, asks that utility programs able to override system and application controls are restricted and tightly controlled. A self-hosted bastion can enforce both in technical terms, but the platform produces evidence for the ISMS rather than replacing it.
Start by deciding who holds which rights. Map each privileged role on servers, databases and Kubernetes to a named identity, and confirm that the bastion can issue access only through that identity, with no shared root or admin password for daily use. In JumpServer, the components to check are the asset, account and permission settings that bind users to systems; in Teleport, the roles and certificate lifetimes that replace shared SSH keys. Ask the vendor or partner to show, in your environment, that a user without a granted role cannot reach the target. Also record which utility programs can override controls, such as configuration tools or database consoles, and confirm the bastion restricts them.
ISO does not certify organizations. Accredited certification bodies do, and they test the ISMS against the standard, including the evidence you hold for each control. Under ISO/IEC 17021-1, a three-year certification cycle includes at least one audit in every calendar year, so the auditor will sample access lists, approvals and session logs across the cycle, not only on the day of the visit. Before engaging an implementation partner, confirm with your certification body which records it expects for 8.2 and 8.18, how far back samples reach and where the evidence should be stored. The ISO/IEC 27002:2022 guidance for these controls is the right reference for writing those expectations down.
Mapping Annex A 8.2 and 8.18 to bastion functions and configuration
This table maps ISO/IEC 27001:2022 Annex A 8.2 and 8.18 to the functions a self-hosted bastion must perform and to the configuration an assessor can check. Read each row as a requirement, the bastion behavior that supports it, and the evidence to keep, with NIST's caution that mapped controls are not always equivalent in mind. The main takeaway is that the control is met by the combination of role design, approvals, and retained logs, not by the bastion product alone.
| Requirement | What the function must do | How to configure it on a self-hosted bastion |
|---|---|---|
| A.8.2 allocation of privileged rights | Grant privileged rights only to authorized users, service accounts and components, and record who holds them | Define named privileged roles per system group, bind them to identity provider groups, avoid shared administrator accounts, and export the role-to-user list for review |
| A.8.2 use of privileged rights | Ensure privileged rights are used only for the purpose approved, with each use attributable to one person | Require individual login through SSO with MFA at the gateway, deny direct root or sudo use outside the bastion where possible, and map each session to a named identity |
| Time-limited elevation | Keep privileged rights active only for the period needed, and end them when the need ends | Use just-in-time access requests with a defined expiry, short-lived certificates or session tokens, and confirm in your edition whether request workflows are included |
| Approval before privileged access | Obtain a documented authorization before high-risk privileged sessions start | Configure ticket or approval workflows for production systems, record approver identity and reason, and confirm which approval features sit in paid editions |
| Access reviews | Review privileged rights at a defined cadence and remove those no longer needed | Schedule recurring reviews of role membership and access lists, keep signed review outputs, and document the owner and due date for each review |
| Session logging and retention | Record privileged activity so an auditor can sample and trace actions to a person and time | Enable session recording for SSH, RDP, Kubernetes and database sessions, set a retention period agreed with the compliance owner, and confirm storage location and search capability |
| A.8.18 privileged utility programs | Restrict tools able to override system and application controls, and control their use tightly | Publish an approved utility list, grant utility access only through a restricted role, and route utility execution through the bastion so each run is logged |
| Credential handling for utilities | Prevent privileged utility use from exposing reusable credentials to operators | Inject credentials at the gateway or vault rather than sharing them, rotate them after use where the platform supports it, and confirm which rotation features need a paid edition |
| Mapping caution and predecessors | Understand that the 2013 controls A.9.2.3 and A.9.4.4 are predecessors, and that NIST notes mapped controls are not always equivalent | Document your own control statement for 8.2 and 8.18, cite the 2013 predecessors only as history, and confirm scope with your certification body before relying on a mapping |
Which open-source bastions fit an ISO 27001 privileged access program
An ISO 27001 privileged access program needs a gateway that allocates admin rights, limits their use and records sessions for later sampling. The options below differ in protocol coverage, edition limits and where the identity decision sits, so the choice should follow the controls you must evidence and the licensing threshold that applies to your organization.
Teleport for certificate-based access
Teleport issues short-lived certificates for SSH, Kubernetes, PostgreSQL, MySQL and other resources, so no shared SSH keys remain to rotate. Session recording with playback is included in both editions. The Community Edition is available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so confirm that threshold before the design starts. Just-in-time requests, access reviews and moderated sessions require Enterprise.
JumpServer for approval-driven bastions
JumpServer is a GPL-3.0 bastion covering SSH, RDP, Kubernetes, databases and web access from one workspace. The free Community edition supports up to 5,000 assets in a standalone topology. Ticket and just-in-time approval workflows, password rotation and SSO are Enterprise features, so an ISO 27001 design that relies on approval evidence should be priced against those features early.
Apache Guacamole as browser gateway
Apache Guacamole gives administrators and vendors browser-based RDP and SSH without installing clients on endpoints. It suits Windows-heavy estates and temporary access paths. Guacamole does not provide the allocation workflow or certificate issuance on its own, so pair it with an identity source and confirm how it records sessions and where those recordings are stored.
Keycloak or midPoint for allocation
The identity provider decides who can be allocated privileged access, and the bastion enforces that decision. Keycloak handles single sign-on, MFA and group claims, while midPoint manages joiner, mover and leaver changes and certification campaigns. Confirm that group membership flows from the directory to the bastion, and that removals take effect without manual steps on the bastion.
Edition fit by control requirement
Choose the edition from the features the control needs, not from the product name. A Community deployment may meet session logging needs while approvals, password rotation or reviews require a paid tier. Map each control in your ISO 27001 statement of applicability to a feature and an edition, then confirm the license terms with the vendor in writing before procurement.
How allocation, elevation and review work on a bastion
Every privileged right on a bastion should trace back to one named person, one approver and one end date, and that chain is what an auditor reconstructs when testing A.8.2 Privileged access rights. Start by defining who may request each role: a named individual requests access to a specific system or account group, a system owner approves it, and the approval is recorded with its reason and scope. Shared administrator logins and standing vendor accounts break this chain, so the design should remove them before the first elevation is configured. Your own process decides who the system owners are, how approvals are escalated when an owner is absent, and what counts as an emergency. Those decisions stay with your organization whatever tool you choose.
Elevation should expire on its own. With Teleport, the certificate authority issues short-lived certificates, so a session ends when the certificate lapses instead of relying on someone to remove a key. Teleport's Enterprise edition adds just-in-time access requests and reviews, access lists and access reviews as part of Identity Governance, and the Community Edition only allows role requests through the CLI, so confirm which of these your edition provides. JumpServer Enterprise lists ticket and just-in-time approval workflows and password rotation among its features. Those features automate more of the request, approval and rotation steps, but they still need a documented approval policy, a list of which systems each approver covers and a test that shows expired access is refused.
Session recording and periodic review close the cycle. Every elevated session should be recorded and linked to the request that authorized it, so that a sampled session can be matched to an approval and a named identity. Review who still holds rights on a fixed schedule, remove what is no longer needed and keep the signed results as evidence. Before go-live, confirm with the vendor and with your own testing where recordings are stored, how long they are kept, who can view them and whether the review reports can be exported. Your ISO 27001 certification body will check the operating evidence over time, so the review records matter as much as the configuration.
Evidence an auditor samples for privileged access and what produces it
This table maps each evidence item an assessor is likely to sample for ISO/IEC 27001 Annex A 8.2 and 8.18 to the component that generates it and the process you must run yourself. Read the middle column for where the record comes from and the right column for what the bastion, identity provider or ticketing system cannot produce on its own. The main takeaway is that a bastion produces logs, but approvals, reviews and leaver removals are process records that need an owner and a cadence.
| Evidence item | Source component | What the reader must add as process |
|---|---|---|
| Access rights register by role | Identity provider groups and bastion role definitions exported on a schedule | Named owner for each privileged role, documented allocation criteria, and sign-off of the register before each review |
| Approval records for elevation | Ticketing or bastion access request workflow, with approver identity and timestamps | Written approval rules saying who may approve which system, and a rule that requesters cannot approve their own access |
| Time-bound grant records | Bastion certificate or session policy showing issue time, expiry and the role granted | Maximum grant durations set by policy, and a check that expired grants were not extended without a new approval |
| Periodic access review sign-offs | Exports of current privileged members from the identity provider and bastion, compared against the register | Review cadence, reviewer independence, a record of removals made after review, and retained signed review packs |
| Session recordings and command logs | Bastion session recording and command capture, forwarded to a SIEM or log store with retention set | Retention period decided with legal and privacy input, restricted playback rights, and a documented process for reviewing sampled sessions |
| Utility program inventory and restriction records | Host inventory and software lists from endpoint or configuration tools, plus bastion controls on permitted tools | Inventory of programs able to override system controls, approval for each exception, and periodic checks that restrictions still apply |
| Removal evidence for leavers and movers | Identity provider deprovisioning logs and bastion account disablement records | Joiner, mover and leaver procedure that links HR events to access removal, with target timelines your organization sets |
Questions buyers ask about ISO 27001 PAM before hiring help
What does an ISO 27001 PAM project cost and what drives the price?
The cost is set by the written scope, not by a list price, and DeployOpen does not publish one. The main drivers are the number of protected systems, the protocols in use (SSH, RDP, Kubernetes, databases), whether session recording needs long retention and search, how many identity sources must be integrated, and whether you need high availability. The software side carries its own cost questions: JumpServer's Community edition is free up to 5,000 assets in a standalone topology, while its Enterprise tiers and features such as Oracle and SQL Server access, ticket and just-in-time approval workflows and multi-tenancy are paid, priced by quote. Teleport's pricing is based on active users and protected resources, and it does not publish prices. Ask any implementation partner for a quote that separates one-time work (design, installation, integration, documentation, evidence preparation) from recurring items (licenses, storage, patching, support and access reviews).
How long does a privileged access rollout take?
Duration depends on how many systems you bring under the bastion, how many access paths exist today, and how much identity and approval design must be settled first. A small set of servers behind one identity provider is a very different job from every database, Kubernetes cluster and vendor path in a multi-site estate. Your side of the work usually includes naming an accountable owner for the access policy, supplying an inventory of privileged accounts and systems, providing the identity provider and MFA details, confirming the network paths to targets, and approving the role model. Ask the partner to state the duration in the written scope, with milestones for the pilot, the first wave of systems, and evidence collection before the certification body's visit.
Can an internal team run an ISO 27001 PAM rollout alone?
Yes, a capable internal team can deploy a bastion, but the hard part is usually the process, not the install. JumpServer's quickstart asks for a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM and installs through a quick_start.sh script, so the installation itself is modest. The effort lies in the role model, approval rules, break-glass procedure, recording retention, configuration of each target, and the evidence set that shows the controls operated over time. Teams without prior ISMS work often lack someone to write the access policy and to run periodic reviews. A useful test is whether your team can answer, for each privileged account, who approved it, when it expires and where its session logs are kept.
Does a bastion alone satisfy ISO 27001 A.8.2 and A.8.18?
No. A bastion is a technical control that supports A.8.2 on privileged access rights and A.8.18 on privileged utility programs, but the standard expects the organization to restrict and manage allocation and use of these rights. A.8.2 asks that only authorized users, software components and services receive privileged access, so you also need documented allocation rules, time-limited elevation, periodic review and removal when roles change. A.8.18 asks that utility programs able to override system and application controls are restricted and tightly controlled, so the bastion must be paired with rules on which tools and scripts engineers may run directly on hosts. The NIST crosswalk maps A.8.2 to AC-2, AC-6 and CM-5, and NIST notes that mapped controls are not always equivalent, so confirm the fit with your auditor.
How do the Teleport Community threshold and JumpServer asset limits affect the choice?
They can decide the edition before any technical comparison. The Teleport Community Edition license applies only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. An organization above either threshold needs a commercial license, and the Teleport feature matrix places moderated sessions, dual authorization and Device Trust in Enterprise. JumpServer Community is free up to 5,000 assets in a standalone topology, but higher tiers add active-standby or full high availability, and the Enterprise tier lists approval workflows and SSO among its features. For ISO 27001, check which controls you need (approvals, recording review, HA) against the edition feature list, and confirm the license position with the vendor in writing.
What will the certification body ask to see for privileged access?
The certification body does not issue a verdict on tooling; it samples evidence that your ISMS operates. Expect requests for the access policy, the register of privileged accounts with owners and approvals, records of time-limited elevations, periodic access review records with decisions, removal evidence for leavers and role changes, the list of privileged utility programs and their restrictions, and session logs sampled from the bastion. Accredited bodies work to ISO/IEC 17021-1 and ISO/IEC 27006-1:2024, and a certification cycle lasts three years with an audit in every calendar year. Confirm with your certification body which samples and formats it wants, and make sure session recordings can be located by user, system and date. Certification itself is issued by the body, not by DeployOpen, which prepares systems and evidence for the assessment.
Does ISO 27001 PAM need a full identity governance system first?
Not necessarily, but you need a reliable source of identity and an access review process. The bastion can authenticate users through an existing directory or SSO provider, and Teleport's Community edition limits single sign-on to GitHub, while its Enterprise edition supports Okta, Microsoft Entra ID, Google Workspace, OIDC and SAML. JumpServer Enterprise lists SSO, RADIUS and LDAP features. If joiner, mover and leaver processes are manual, the access list will drift, and auditors will find accounts that outlive their owners. Decide early whether reviews will run from the bastion's own role data or from a separate governance platform, and confirm that the chosen approach can produce a complete, dated list of who held which privileged access.
What a bastion alone does not satisfy in ISO 27001
A bastion enforces and records access, but ISO/IEC 27001 asks for a management system around it. The cards below cover the decisions, owners and records that the organization must maintain, because an auditor will test them alongside the session logs.
Risk assessment and access policy
The risk assessment and the access control policy determine who is entitled to privileged rights, on which systems, and for what purpose. The bastion can only enforce the rules it is given. Check that each privileged role traces back to a documented risk treatment decision, that the policy names who approves exceptions, and that the platform's role model reflects that policy rather than a copy of an old directory group list.
Ownership of access reviews
Periodic review of privileged access is a management activity, so someone must own it. Define who certifies each privileged account and role, how often, and what happens to access that is not confirmed. Record each review decision with a date and reviewer. An export of current entitlements from the bastion is evidence of access, but the signed review is what shows the control operated.
Break-glass procedures
Emergency access must exist for outages in the bastion or its identity provider, and it creates a gap in normal controls. Document who may invoke break-glass, where the credentials are held, how use is detected and alerted, and how the account is reset afterwards. Confirm with your platform whether break-glass sessions are recorded like any other session, and test the procedure before an auditor asks to see it.
Utility programs outside the bastion
ISO/IEC 27001 control A.8.18 covers utility programs that can override system and application controls. A bastion does not see tools run locally on a server, such as configuration utilities, database command-line clients or scripts with root rights. Build an inventory of these programs per host, restrict who can run them, and log their use through the host's own audit mechanisms, then state how that inventory is kept current.
Shared accounts on target systems
If vendors, operators or scripts still log in with shared local accounts on target systems, the bastion records a session but cannot prove which person acted. Inventory every shared account, decide which can be retired, and where one must remain, make sure credential access is checked out and logged. Confirm that the platform can rotate or inject these credentials so users do not hold them directly.
Management review and evidence ownership
Top management must review the information security management system, including privileged access performance, incidents and audit findings, and act on what it finds. The platform supplies logs, reports and access lists, but the organization owns the management system, the decisions and the minutes. Assign a named owner for the privileged access process and keep the review records together so the evidence trail is complete.
What to confirm with your certification body before the audit
Start by confirming the certification body's cycle and sampling approach, because they shape what evidence you must keep ready. Under ISO/IEC 17021-1, a management system certification cycle runs three years, with at least one audit, either surveillance or recertification, in every calendar year. For a privileged access topic, that means access lists, approval records and session logs must be retrievable across the whole cycle, not only at the initial assessment. Ask the body how it will select samples from your bastion's records, which period it will cover, and whether it expects evidence for leavers and role changes as well as current administrators.
Confirm which edition of the standard the audit will use. ISO/IEC 27001:2022 is the third edition, and its Annex A is normative with 93 controls in four themes, a structure that replaced the 114 controls of the 2013 edition. Under IAF MD 26:2023, all certifications to the 2013 edition had to expire or be withdrawn by 31 October 2025, so any older certificate you hold will not carry over. Map your privileged access records to A.8.2 and A.8.18 using the 2022 control titles, and ask whether the body expects the attribute and purpose documentation the 2022 edition introduced.
Ask how the body operates under ISO/IEC 27006-1:2024, which accredited certification bodies had to apply to all clients by 31 March 2026 under IAF MD 29:2024. Confirm the accreditation status of the body through the IAF CertSearch database, since ISO points to it for checking accredited certificates. Finally, agree in writing which samples, sampling rules and retention periods your session recordings must satisfy, and test one full sample request against your bastion before the audit date.
How DeployOpen scopes, deploys and supports an ISO 27001 PAM program
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For ISO 27001 privileged access, that means agreeing which systems, accounts and evidence the bastion must cover before any build starts, then handing over the access records and procedures an internal team or certification body will need to see.
How we scope
- Inventory the servers, databases, Kubernetes clusters and vendor entry points that hold privileged access in scope for the ISMS
- Map each privileged role to its Annex A 8.2 allocation, approver and review owner in the written scope
- Confirm which edition, identity source and session retention rules the scope requires before any quote is issued
How we build
- Deploy the chosen bastion in the client's cloud accounts, data center or air-gapped network, with no dependency on DeployOpen systems
- Configure time-limited elevation, dedicated admin identities and session recording, then test them against the agreed scope
- Document approval steps, break-glass procedures and the audit log fields an auditor is likely to sample, reviewed with the client
How we hand over
- Deliver runbooks for allocation, review cycles, log export and access revocation, written for the client's own operators
- Provide a control evidence pack that maps configuration and logs to the agreed Annex A 8.2 and 8.18 scope
- Agree a handover session so the client's team can run the platform without DeployOpen involvement
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, sized to the written scope
- Patch and upgrade the access layer on a schedule the client approves, with change records kept in the client's own systems
- Keep the evidence pack current as systems, roles and review cycles change, and confirm final certification readiness with the client's certification body
