Open source PAM for SOX ITGC privileged access

Open source PAM for SOX IT general controls: what auditors sample

If your external auditor tests privileged access to financial systems under internal control over financial reporting (ICFR), a self-hosted bastion can produce the admin access lists, approval records and session logs that testing typically samples. SOX does not prescribe a tool, though, so the bastion is evidence support for controls you still have to design, operate and prove. Management owns the assessment; the auditor decides what to test and how much. The framework basis is Section 404 of the Sarbanes-Oxley Act, which requires management's annual ICFR assessment and, for accelerated and large accelerated filers that are not emerging growth companies, an auditor attestation under 15 U.S.C. 7262. Management's evaluation generally follows SEC Release 33-8810, which says the IT general controls (ITGCs) relevant to a given company depend on its facts and circumstances. External auditors work under PCAOB AS 2201 and assess IT risk under AS 2110, which requires understanding the ITGCs that support automated controls. COSO's 2013 framework, Principle 11, asks the organization to select and develop general control activities over technology. No SEC rule or PCAOB standard publishes a catalog of ITGCs, so your control list must be written from your own risk assessment.

Start by asking your auditor which ITGC areas and which systems are in scope for the current year, and which access controls they expect to rely on. AS 2110 links privilege creep to segregation of duties, so the first deliverable is a reviewed list of who holds administrative rights on the ERP, general ledger, databases and underlying servers, with a stated business reason for each. Confirm with the auditor whether they want that list generated by the bastion's role and asset data or extracted from the source systems, because the answer changes what the bastion must reconcile. Treat the bastion's recordings as one input, not the whole control: the approval, periodic review and removal steps still need documented owners and retained evidence.

Mapping SOX ITGC access expectations to bastion functions

This table maps each SOX ITGC reference that touches privileged access to what management and auditors need from the function, and how to configure JumpServer or Teleport to produce that evidence. Read it as a checklist: the right-hand column is where the configuration work sits, and the gaps column names what the tool will not settle on its own.

Framework basis	What the function must do	How to configure JumpServer or Teleport	What tooling leaves to process
AS 2201 access controls (benchmark reliance)	Keep access controls over financial systems stable enough that a tested automated control can be relied on across the period	Define fixed roles per financial system, restrict changes to role and asset mappings, and export role and permission configuration at each review point	Change tickets, sign-off on each role change and proof that the configuration did not drift between tests
AS 2110 segregation of duties	Stop IT staff from holding admin rights beyond their duties, including combining development and production access	Create separate admin and everyday accounts, split roles for database, server and application access, and deny production roles to developers	Owner of the conflict matrix, documented exceptions and the periodic review that catches role creep
SEC Release 33-8810 access to programs and data	Limit who can reach programs, data and the administrative layer, and show that access is authorized	Map SSO groups to bastion roles, require MFA at login, and restrict access to financial database and application assets by group	Authorization records from the business owner and the process that approves and removes each named user
COSO Principle 11 (general control activities over technology)	Select and develop controls over technology that support financial reporting objectives	Document the bastion as a control with its objective, owner and operating frequency, and keep its settings under version control	Control narrative, owner accountability and the decision record for why each control is designed as it is
Rule 13a-15(c) evaluation	Evaluate the access controls against a recognized framework at each fiscal year end, with evidence of testing	Schedule exports of user lists, role assignments and session logs to a retained evidence store before each year-end evaluation	Test plan, deficiency evaluation and management sign-off on the results, which the tool cannot provide
Session logs and approvals (sampled evidence)	Show that privileged sessions were recorded, approved where required and attributable to a named person	Enable session recording and command logging, set approval workflows for production assets, and forward logs to the SIEM	Matching approval to session, retention decisions and proof that recordings were reviewed when required
Emergency (break-glass) access	Provide an audited path for urgent fixes without leaving standing admin rights	Configure time-limited elevation or a restricted emergency role that triggers an alert and a post-use review	Criteria for when break-glass may be used and evidence that each use was reviewed afterward

Which open-source bastions fit SOX access evidence

Two open-source bastions cover most SOX access evidence needs, but their editions differ in ways that change what you can produce for auditors. The cards below compare the edition thresholds, the approval and access request features, and the identity sources that keep joiner and leaver records accurate.

JumpServer and the asset ceiling

JumpServer is licensed under GPL-3.0 and its free Community edition is listed for up to 5,000 assets in a standalone topology. Count every server, database and Kubernetes resource that touches financial systems before choosing, because the Enterprise tiers differ in asset count and high availability. Confirm with the vendor whether your topology needs active-standby HA, since that is a paid tier.

Approvals and password rotation in JumpServer

Ticket and just-in-time approval workflows, along with password rotation, are listed as Enterprise features in JumpServer's pricing comparison. These controls are often the ones SOX testers ask about first, since they show who approved a privileged session before it started. If your control design depends on approvals, budget for an Enterprise edition and confirm in writing which approval records export to your evidence store.

Teleport certificates and session recording

Teleport issues short-lived certificates in place of shared SSH keys and Kubernetes tokens, which gives each administrator session an individual identity and expiry. Session recording with playback is included in both the Community and Enterprise editions. This makes Teleport a strong fit for recording administrator activity on databases and servers, provided you confirm how long recordings are retained on your own storage.

Teleport Community license threshold

The Teleport Community Edition license is available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patches. A public company subject to SOX will usually exceed these limits, which means the Community build is not an option for production financial systems. Have counsel review the license text before any pilot.

Access requests and access lists in Teleport

In Teleport Community Edition, roles can only be requested through the CLI. Just-in-time access requests and reviews, access lists, access reviews, locks and SCIM provisioning sit in Enterprise Identity Governance. These features map most directly to the periodic access review evidence SOX testers request, so confirm that the review export format meets what your auditors expect.

midPoint or Keycloak as the identity source

The bastion only knows the users it is told about, so joiner, mover and leaver records should come from an authoritative source. midPoint handles identity governance with joiner and leaver provisioning and certifications, while Keycloak supports LDAP and Active Directory federation and SAML or OpenID Connect single sign-on into the bastion. Document which system is the source of truth for each privileged account, since auditors will test the link between HR events and removals of access.

How edition limits change the SOX design

A Community-only design relies on the open-source edition for session capture and access configuration, with approvals and reviews handled outside the tool. JumpServer's Community edition is free for up to 5,000 assets in a standalone topology, and Teleport's Community Edition builds carry license conditions on organization size and revenue, so confirm eligibility before committing to this path. Teleport's Community roles can only be requested through the CLI, which pushes request evidence into your own ticketing records.

Session logs: Session recording with playback is included in both Teleport editions, which gives you a native log of who connected and what they did.
Access lists: Role and user configuration is the primary list. Export it on a schedule and keep dated snapshots.
Approvals: Approvals live in your ticketing system. Link each ticket ID to the session and role change it authorized.
Access reviews: Quarterly reviews must be performed and signed off manually, with the reviewer's evidence retained.
Single sign-on: Teleport Community limits SSO to GitHub, so confirm how the identity provider mapping will satisfy your identity controls.

Before committing, confirm with the vendor whether Community features cover every system in scope and whether your organization meets the license conditions.

How a SOX-ready bastion rollout runs

The sequence turns admin access to financial systems into a documented, scoped population with named approvers and session evidence that an auditor can sample for the whole audit period. Each step closes with an artifact that the next step depends on.

Scope financial systems and their admin paths
Finance, IT and the external auditor agree which systems support in-scope financial reporting, such as the general ledger, subledgers, consolidation tools and the databases and servers beneath them. For each system, the team maps every route an administrator, vendor or engineer uses today, including direct SSH, RDP, database clients, cloud consoles and shared accounts. The output is a scope register that lists each system, its owner, its access paths and the reason it is in scope, signed off by the control owner.
Confirm the ITGC population with the auditor
Before any build work, the team asks the external auditor which IT general control areas, including access to programs and data, and which privileged populations they expect to test. The team records the auditor's answers about the population definition, the sample sources and the period under review. This step is complete when the agreed population definition is written down and both management and the auditor have acknowledged it, so that the bastion produces the lists and logs the auditor will actually request.
Deploy the bastion and the identity source
The platform team installs the chosen bastion, such as JumpServer or Teleport, inside the company's own infrastructure and connects it to the workforce identity source, usually the corporate directory or an SSO provider. Roles, asset groups and protocol access are defined to match the scope register rather than the old shared accounts. The step is done when a test administrator can sign in with MFA, reach only the assets their role allows, and produce a session record that is stored where the retention policy says it should be.
Migrate admin access and remove shared credentials
Each administrator, vendor and engineer account in the scope register moves to a named identity that routes through the bastion. Shared root and service-style logins are either retired or vaulted behind the bastion, and the team records which credentials were rotated and when. The team also confirms that direct network paths to in-scope systems are closed or restricted so that the bastion is the practical route. The output is a reconciliation between the scope register and the bastion's user and asset lists, with every exception documented and assigned an owner.
Set approval and access review procedures
Control owners write the procedures for granting, changing and removing privileged access, including who approves each request, how emergency or break-glass access is authorized and reviewed afterward, and how often the admin access list is certified by a business owner. Where the chosen edition supports approval workflows or just-in-time requests, the team configures them to match the written procedure. Where it does not, the team states the manual step that fills the gap. The step closes when the procedures are approved, the approvers are named, and a test request has been approved and logged end to end.
Rehearse a sample pull before the audit period
Before the audit period starts, the team runs a dry-run of the evidence the auditor is likely to request: the current admin access list, a sample of approval records, a selection of session logs and the change history for role assignments. Each artifact is checked for completeness, for the correct date range, and for whether a reviewer can tie a session back to an approved request and a named identity. Gaps found in the rehearsal are fixed as process or configuration changes. The sequence is complete when the team can produce each artifact on request without manual reconstruction.

Evidence auditors request for privileged access

This table lists the privileged access artifacts an ITGC tester typically samples, which component produces each one, and what to confirm before relying on it. Read it as a checklist for the evidence pack: a bastion produces much of the raw record, but the access list, review sign-offs and leaver evidence depend on your identity source and your process.

Artifact	Produced by	What to confirm with the platform and your process
Current admin access list for in-scope financial systems	Identity provider group membership exported alongside bastion role and resource mappings (JumpServer or Teleport)	Confirm the export shows who can reach each database, server and application that supports financial reporting, and that it can be generated at a point in time
Access approval records	Bastion ticket or access request workflow, where the edition supports it (for example, JumpServer approval workflows or Teleport just-in-time requests)	Confirm which approval features sit in the edition you pick, and that approvals are stored with approver identity and timestamp
Session recordings for administrator and vendor sessions	JumpServer or Teleport session recording, stored on your own storage	Confirm recording retention periods, integrity protection, access controls on the recording store and whether playback is available in your edition
Session command and login logs	Bastion audit log, forwarded to your SIEM such as Wazuh	Confirm log fields include user, target, source address and time, and that logs cannot be edited by administrators of the bastion
Periodic access review sign-offs	Review records from your governance process or an identity governance tool such as midPoint	Tooling does not perform the review. Confirm reviewers, scope, frequency and evidence of follow-up on removals
Leaver removal evidence	Identity provider deprovisioning log plus bastion account and role removal records	Confirm the time between termination and removal in both systems, and that removals are recorded and sampled
Configuration and role exports	Bastion configuration export and change history from the platform's admin logs	Confirm who may change roles, MFA settings and recording policies, and how changes to these settings are logged and reviewed

What tooling alone does not satisfy for SOX

A bastion produces logs and lists, but the company still designs the controls that decide whether those records count as evidence. The cards below cover the process decisions that auditors test alongside the platform. Management owns the control design; the external auditor decides whether the design and evidence are sufficient.

Access review cadence and reviewer independence

Management must define how often privileged access lists are reviewed, who performs each review, and how the reviewer confirms that each name and role is still needed. A reviewer who administers the same systems cannot independently assess their own access, so the reviewer should sit outside the administrative group. Ask the auditor which review frequency and population they expect for each financial application and database, and retain signed review records that show what was checked and what was removed.

Defining who is privileged

Bastion roles do not define privilege on their own. The company must decide which accounts count as privileged in each financial application, database and operating system, including vendor support accounts, batch service accounts and database owner roles. PCAOB AS 2110 warns that IT staff holding access beyond their duties can break segregation of duties, so this definition is the baseline for every later test. Document it per system and keep it current as systems change.

Break-glass governance

Emergency access bypasses normal approval, so auditors look closely at it. Define who may invoke break-glass credentials, the conditions that justify use, how the account is protected at rest, and how each use is reviewed after the event. Illustrative example: a database administrator uses an emergency account at night, and the next business day a manager compares the session recording with the incident ticket. Confirm that the review happens and is recorded.

Change management for the bastion

The bastion is itself a system that controls access to financial applications, so its configuration, role mappings, recording settings and software versions fall within IT general controls. Changes to these need approval, testing and a record of who made them. Confirm how upgrades are tested before release, and who can change session recording or retention settings, because a silent change there would remove the evidence the auditor samples.

Reconciling bastion roles to application roles

A bastion role such as an administrator on a server may not match the role that grants posting rights, approval rights or database write access in the financial application. Someone can hold broad bastion access while the application shows a narrower role, or the reverse. Build a mapping table that links each bastion role to the application and database roles it enables, and reconcile it on the same schedule as the access review. Without this, the admin access list the auditor receives may be incomplete.

Ownership of the control design

The company decides which controls exist, how they operate and what evidence they produce. Open-source tooling and implementation partners can build the mechanisms, but the auditor decides whether the design and the samples are sufficient for their testing. Agree the control narrative, evidence list and sample population with the external auditor before the testing period starts, and keep a written record of each decision so the design is defensible.

Questions CFOs and IT leaders ask before hiring help for SOX PAM

What drives the cost of a SOX-scoped bastion on open source PAM?

The main drivers are the edition you choose, the number of managed assets, the number of financial systems in scope, and how deeply the bastion must integrate with your identity provider. Edition matters because some controls auditors ask about, such as approval workflows, password rotation for certain databases and high availability, sit in paid tiers on JumpServer and in Enterprise editions on Teleport. Asset count and financial system count set how much access policy, connector configuration and testing you need. Identity integration sets how much work goes into SSO, group mapping and removing access when people leave. Ask any implementation partner for a quote that separates one-time work (design, deployment, integration, evidence design) from recurring work (upgrades, access reviews, support), and that states which features the quote assumes are licensed.

Can our internal IT team build a SOX PAM bastion without a partner?

Often yes for the technical install, and often no for the audit alignment. JumpServer's Community edition installs on a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM using a quick_start.sh script, and Teleport runs as a single binary, so a capable platform team can stand up a lab quickly. The harder work is mapping access to financial systems, designing approval and break-glass rules that an auditor will accept, configuring session retention, and producing evidence in the form auditors sample. Those tasks need people who understand both the platform and ICFR testing. Assess whether your team has that combination, how many people can carry it through the audit period, and who will run it after go-live.

What does the work need from finance and internal audit?

Finance and internal audit need to define which systems and accounts affect financial reporting, because the bastion's scope follows that list rather than the whole estate. Finance should name the business owners of each financial application who approve access, and internal audit should agree the control descriptions, the sampling approach, and the evidence format before configuration begins. Expect finance to confirm which roles are allowed to change ledgers or approve journal entries, since segregation of duties conflicts are often the finding that matters most. Ask your external auditor early which evidence they will request and how far back the period runs, because that determines retention settings and reporting design.

How long does it take to align a bastion with the audit period?

The duration depends on the scope, the number of systems, and whether the control design has been agreed with the auditor before go-live. Teams usually lose time on three points: identity integration and clean-up of existing admin accounts, agreeing how approvals and emergency access will be documented, and confirming that recordings and access logs are retained and retrievable for the whole audit period. A control that goes live partway through a fiscal year can still be tested, but the auditor will want to see operation for the period it covers, so the go-live date and the start of the testing window should be planned together. Ask any partner for a written timeline that names these dependencies and the review gates.

Does DeployOpen issue SOX audit attestations or certifications?

No. DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Under Section 404, management performs the annual ICFR assessment, and for accelerated and large accelerated filers that are not emerging growth companies, an independent auditor attests to it. Those conclusions come from your management and your auditor. What DeployOpen can provide is a configured, documented bastion and evidence packages that your team and auditor can review, with the design choices explained so that the auditor can test them.

What does the SEC's 2020 estimate for auditor attestation savings tell us about PAM cost?

Very little directly. Release 34-88365 estimated that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, made up of roughly $110,000 in audit fees and $100,000 in other costs. That figure concerns the cost of the auditor's attestation work for a category of issuers, not the cost of building privileged access controls. It does not cover platform licensing, integration, recording storage, or the internal effort to run access reviews. Its only relevance to a PAM budget is the reminder that ICFR testing costs exist whether or not you are exempt, and that the controls being tested still have to operate. Use it as context for the overall compliance budget, and build the PAM estimate from the cost components above.

What breaks most often when a bastion is first tested by auditors?

In most reviews, the admin access list does not match the actual permissions on the target systems. Shared or local accounts that bypass the bastion, service accounts with standing access, and vendor accounts created outside the approval process are the usual causes. The second common gap is evidence: session recordings exist but cannot be linked to a ticket, a named user or a business reason, or they were purged before the testing window closed. Check whether your design lets you produce, for any sampled date, the list of who held access, who approved it, and which sessions they recorded. Test that retrieval before the auditor asks for it.

How DeployOpen prepares SOX evidence without issuing an opinion

DeployOpen plans, implements, hardens and documents the bastion, and prepares the controls and evidence that your assessment will rely on, but it does not test those controls or conclude on them. Management owns the ICFR assessment under Section 404 of the Sarbanes-Oxley Act, and for accelerated and large accelerated filers that are not emerging growth companies, an independent auditor issues the attestation. DeployOpen's role is to make the access lists, approval records, recording configuration and change history easy to pull and easy to explain, so that management and the auditor can test them. DeployOpen does not issue audit reports, attestations or certifications, and nothing in an engagement should be presented to your auditor as one.

The work runs on a written, fixed scope agreed before anything is installed. That scope should name the systems in the financial reporting boundary, the roles and approval paths that will be configured, the session recording and retention settings, the identity provider integration, and the evidence pack that will be handed over. Ask for the scope to state who approves each control design decision, including your IT general controls owner and your external auditor's view of the relevant areas. Optional retainers can cover upgrades, configuration drift checks and continuous support after go-live, and should be priced separately with their response expectations written down. Ask any partner to put every service level in the contract, since no SLA is implied by the product itself.

How DeployOpen scopes, delivers and supports SOX-ready privileged access

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source privileged access platforms inside your own infrastructure. For SOX IT general controls, we prepare the access lists, approval records and session evidence that management and external auditors can test, and we agree in writing which parts remain with your process owners.

How we scope

Engagements are fixed-scope, with systems, protocols and deliverables agreed in writing before work starts.
We map which financial systems, databases and admin paths fall within the ICFR scope your auditors have identified.
We confirm with your team which edition, identity source and session retention settings the written scope requires.

How we build

We deploy the bastion in your cloud account, data center or air-gapped network, with access to target systems restricted to it.
We integrate it with your identity provider, MFA and approval workflow so each admin login ties to a named, unique identity.
We test privileged access paths and session logging against the controls documented in the agreed scope before handover.

How we hand over

You receive documentation of configuration, roles, approval rules, recording locations and the evidence each report produces.
We document the process controls that tooling cannot enforce, such as access reviews, ticket linkage and periodic recertification.
Your team receives a walkthrough showing how to export access lists, approval records and session logs for an auditor sample.

How we support

Ongoing support, upgrades and continuous testing are available as retainers agreed separately from the initial scope.
We can keep backups, patching and configuration documentation current as the platform and your financial systems change.
Before each audit cycle, we can help your team confirm that evidence still matches the controls described in the scope.

Open source PAM for SOX IT general controls