authentik for SOX ITGC access controls

How authentik supports SOX ITGC access controls and where it stops

authentik can centralize authentication for financial applications, support provisioning and removal of access, and produce event logs that you can inspect. It does not satisfy SOX IT general controls by itself, because ITGCs are management processes: someone must define the control, approve access, perform reviews and retain evidence. Treat authentik as the system that enforces and records access decisions, and plan the surrounding process as a separate workstream. No SEC rule or PCAOB standard publishes a catalog of IT general controls. The SEC's Release 33-8810 says the relevant aspects vary with each company's facts and circumstances, and names access to programs and data as one example area. Scope therefore starts with your own list of financial applications and the controls your auditors expect over them. DeployOpen prepares systems, controls and evidence for that assessment, but does not issue audit reports, attestations or opinions. Your external auditor makes that determination.

Edition choice matters for this topic. The open-source edition is MIT licensed for most of the code, and the pricing page lists it as free with community support only. The pricing page places several features in the Enterprise edition, including privileged access management, enhanced audit logging, password history and ticket-based support for subscriptions over $1k. If your design depends on privileged session control or on audit log detail that auditors will sample, confirm in writing which of those capabilities you need, which edition provides them, and whether the license terms in the authentik/enterprise/ directory apply to your deployment. Ask the vendor to confirm current feature availability, because the pricing page is the only source used here for edition contents.

Mapping SOX access requirements to authentik capabilities

This table compares each SOX-relevant access requirement from the PCAOB standards with what authentik provides, the configuration it needs and the work that stays with your organization. Read each row as a question an auditor will ask, then check whether the capability and the customer process together answer it. Authentik centralizes sign-in and records events, but the approvals, reviews and terminations that prove control operation remain your process.

Requirement	authentik capability	Configuration needed	Remains a customer process
Unauthorized access to data (AS 2110, B4)	Central authentication through OAuth2/OIDC, SAML and LDAP providers, so applications share one sign-in point	Bind each in-scope application to a provider, require MFA through authentication flows, and disable local application logins where the application allows it	Confirm which applications can be fully federated, and document any local accounts that must remain
Access persisting after termination (AS 2110, B4)	Deactivating a user in authentik stops new sign-ins through its providers, and SCIM provider sync can remove accounts in connected SaaS applications	Map the HR termination event to user deactivation, and configure SCIM outbound provisioning for applications that support it	Terminations must be triggered on time, and deprovisioning in applications without SCIM must be checked by hand or by ticket
Privileged access beyond duties and segregation of duties (AS 2110, B4)	Group membership and policy bindings control which applications and roles a user can reach, and enterprise edition lists privileged access management as an option	Create separate admin groups and separate user accounts for administration, and bind policies so privileged applications require a distinct group	Approve each privileged grant, review conflicting combinations of duties, and confirm whether privileged access management is needed for your scope
Operating effectiveness, inquiry and inspection (AS 2201, paragraphs 44 and 45)	Audit events record logins, changes and policy activity, and enterprise edition lists enhanced audit logging	Forward authentik events to your log platform, set retention to match your audit period, and test that sampled events can be retrieved	Auditors interview owners, observe operations and re-perform reviews, so the review records, sign-offs and owner statements must be kept by your team
Access controls within the IT control environment (AS 2201, B33)	Authentication, group, and provisioning settings form a stable configuration that can be benchmarked and tested over time	Export and version the configuration, restrict who can change providers and policies, and log configuration changes	Change management over authentik itself, including version upgrades and reviews of configuration drift, must be defined and evidenced
Management evaluation of relevant IT general controls (SEC Release 33-8810)	Gives management a documented access model that can be mapped to in-scope financial applications	Identify which applications feed financial reporting and scope authentik controls to them	Scope decisions, risk ratings and the conclusion on control effectiveness belong to management, not to the product

Evidence auditors test and how to keep it

External auditors test access controls by combining inquiry, observation, inspection of documentation and re-performance, as PCAOB AS 2201 describes. The cards below cover the records that let your team answer each of those methods, and the settings you must decide and confirm before the audit period starts.

User lists and group membership exports

Auditors commonly ask for a complete list of accounts with their group memberships at a point in time, then compare it against approved access. In authentik, export users and group membership from the admin interface or API on a set schedule, and keep each export with its date and the person who ran it. Check that service accounts and break-glass accounts appear in the export, since auditors will look for them. Flag any account with access to finance applications that lacks a matching approval. Note that the export is only as complete as the directory it reads from.

Provisioning and deprovisioning tickets

For each joiner, mover and leaver, auditors will want to trace the request, its approval, and the change in authentik. Link each ticket ID to the authentik account or group change and to the event that recorded it. Test removals on a sample of terminated staff: the account should be disabled and removed from application access in a time frame your policy defines. Access that persists after termination is the risk AS 2110 describes, so this card is where that risk is demonstrated. Confirm how your HR process triggers removals, because authentik will only reflect the change it is given.

Access review sign-offs

A periodic access review is evidence only when a reviewer with authority compares current access to the business need and records the outcome. Export the membership of each in-scope application or group, have the owner mark each entry as retained or removed, and file the signed result. Keep the removal tickets that followed each finding. Auditors check whether the reviewer had the competence and authority to approve, so record the reviewer's role. Decide the review frequency and scope in your own control design, since this guidance does not set them.

Audit log retention in PostgreSQL

authentik stores its configuration and data, including events, in PostgreSQL, so the database is the primary source for authentication and administrative activity. Confirm which events are recorded in your version and how long they are kept, then set retention to match your audit period and make sure database backups cover that window. Test a restore, and confirm that a sampled event can still be retrieved after the retention job runs. Enhanced audit logging is an Enterprise feature on the authentik pricing page, so confirm with the vendor whether your edition includes it before relying on it.

SIEM forwarding of authentication events

Forwarding events to a SIEM gives you a copy outside the identity platform, which helps when an auditor asks whether logs were altered or deleted. Define which event types are sent, the transport and the destination retention, and test that a sample login, failed login and admin change appears in the SIEM with the correct timestamp and user. Alert on changes to administrator and privileged groups. Confirm the log format and forwarding method for your release in the authentik documentation, since they are not set by this page.

Change records for policies and configuration

Auditors test whether changes to authentication policies, flows, providers and group-to-application bindings were authorized, tested and reviewed. Keep the configuration in version control where your team can (for example, exported blueprints), require a ticket reference in each commit, and record who approved each change. Compare the running configuration to the approved version during your review period. Changes made directly in the admin interface without a record are a common finding, so decide early how emergency changes are documented and reviewed afterward.

Deployment options that change the control design

Docker Compose is the simplest path. authentik's Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production. The stack is a server container (core plus an embedded outpost), a worker container for background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. Because one host runs everything, the ITGCs over the platform rest mostly on host administration and the Compose file itself.

Backup scope: A database dump covers configuration and identity data, but uploaded files and the Compose and environment files must be backed up separately.
Change control: Pin image tags in version control and treat each tag change as a reviewed change with a ticket, a test run and a rollback plan.
Access to the host: Restrict shell and Docker socket access to named administrators, since those users can alter configuration outside the authentik interface.
Evidence: Retain the Compose file history, image digests deployed, and dated backup restore records as the population for the change and recovery tests.
Scale limits: Confirm with your own sizing whether a single host meets your user volume and availability expectations before committing an in-scope system to it.

Before relying on this model, confirm the host hardening baseline, the backup restore test frequency and who approves changes to the Compose file.

Configuration sequence for SOX-ready access control

This sequence turns authentik into a controlled source of access for in-scope financial applications, with each step leaving a record an auditor can inspect. It starts with scope and ownership and ends with the review and change control that keep the setup defensible over time.

Confirm in-scope applications and their owners
Finance, IT and internal audit agree which applications and data stores affect financial reporting, using the company's own ICFR scoping. Each in-scope system gets a named business owner who approves access and a technical owner who administers it. The output is a written inventory of systems, owners and the access each role needs. Confirm the scope with your external auditor before building anything, because the SEC guidance leaves the relevant IT general control areas to each company's facts and circumstances.
Deploy authentik on controlled infrastructure
The platform team deploys authentik in infrastructure the company controls, with its server and worker containers and a separately managed PostgreSQL database. The bundled database in the Kubernetes chart is intended for demonstration and test environments, so production should use a managed PostgreSQL instance. Restrict administrative access to the deployment itself and record who holds it. The check is a working deployment whose version, hosting location and database ownership are documented in the change record.
Connect the directory or HR-driven source
Connect authentik to the directory or upstream source that holds the authoritative joiner and leaver data, such as an existing directory or HR-fed process your organization already trusts. Confirm which system is the source of truth for account creation and disablement, because authentik should inherit that decision rather than create a second one. The check is a test account that appears in authentik from the source and is disabled when it is disabled upstream.
Define groups that mirror job roles
Build groups that match approved job roles and map each group to the access the business owner signed off on. Keep application access in groups rather than assigning it user by user, so that an access review reads as a list of roles and members. Document the approval for each group. The output is a role-to-group matrix that the business owners have signed, which becomes the baseline for later reviews and segregation of duties checks.
Bind applications through providers
For each in-scope application, create the matching provider in authentik (OAuth2/OIDC, SAML, LDAP, proxy or another type that fits the application) and bind only the approved groups to it. Test that a user outside the bound groups is denied, and that a user removed from a group loses access on next sign-in. Keep the provider configuration in version control so changes are traceable. The check is a documented test result for each application showing both the granted and denied cases.
Set up privileged groups with separate admin accounts
Create privileged groups for administrators of authentik and of the financial applications, and require administrators to use separate accounts from their everyday identities. Limit membership to named people approved by the business and technical owners, and check that no IT staff member holds access beyond what their duties need. Enterprise features such as privileged access management are listed on the pricing page, so confirm with the vendor whether the edition you need includes them. The output is a list of privileged members with approvals attached.
Configure audit log export and retention
Configure authentik's event logging and export those events to a log store that administrators of authentik cannot edit. Confirm which events are captured, such as sign-ins, group membership changes and provider changes, and whether your edition includes enhanced audit logging, which the pricing page lists as an Enterprise feature. Agree the retention period with your auditors and compliance team. The check is a test change in authentik that appears in the external log store within the window your team has defined.
Define the periodic review and evidence capture
Set a review cadence with the business owners, then run a review that compares each application's current group membership against the approved role matrix. Capture the exported membership list, the reviewer's sign-off, and the removals made as a result, and keep them together by review period. Auditors test operating effectiveness by inspecting this documentation and re-performing the control, so the records must show who reviewed what and when. The output is a completed review file for each in-scope application.
Document change control for authentik itself
Treat authentik configuration and its upgrades as changes subject to the company's own change management. Record each change with its approver, and plan upgrades to stay on a supported release line, currently 2026.5.x or 2026.8.x according to the security policy, which also announces security releases at least 24 hours in advance. Confirm the upgrade path with the vendor before scheduling work. The check is a change log in which every authentik configuration or version change has an approval and a test record.

What authentik does not cover for SOX

authentik enforces sign-in and can record access events, but several SOX controls sit outside the identity provider. The cards below name the processes your organization must own, decide and evidence before an auditor will rely on the access controls authentik provides.

SOX scoping and control mapping

Deciding which systems, applications and data fall within ICFR is a management judgment that depends on your financial reporting risks, not on the identity provider. authentik only enforces access to applications you have connected to it. Before deployment, document which in-scope applications and databases are federated, which use local accounts, and which are reachable by privileged paths. SEC guidance says the IT general controls relevant to an ICFR evaluation vary with each company's facts and circumstances, so the scope decision must be recorded by your team.

Management's ICFR assessment

Management must evaluate internal control over financial reporting as of each fiscal year end against a recognized framework, and that evaluation is performed and signed by people in your organization. authentik can supply configuration exports and event logs as inputs, but it does not produce a management assessment, a deficiency classification or a conclusion. Your team owns the assessment memo, the severity decisions and the remediation tracking, and should confirm which framework and evidence standard the assessment uses.

End-to-end recertification campaigns

authentik can show group memberships, application bindings and last-login data, which are useful inputs to an access review. It does not run a recertification campaign on its own. Your organization must define the reviewers for each application, the review frequency, the approval and revocation steps, and the record of who approved what. Confirm in your own environment whether the reviews are performed in authentik, in a separate governance tool, or in a spreadsheet, and retain the signed output.

HR termination and transfer workflows

authentik can disable or remove accounts quickly once a termination is recorded, but it does not learn about terminations or transfers from your HR system unless you connect that source and define the rules. Your organization owns the leaver checklist, the timing expectations, the handling of contractors and the process for transfers that change access. Test the path from an HR event to a disabled account, and retain the ticket or record that proves the timing.

Applications that cannot be federated

Some financial applications, legacy databases and vendor consoles cannot be placed behind authentik through a supported protocol. Access to these systems remains under local accounts or shared credentials that authentik does not govern. Your team must inventory these systems, decide whether to federate, isolate or manage their accounts through a separate process, and document compensating controls. Each unfederated system needs its own owner and review, or it becomes a gap an auditor will find.

Identity governance tooling and audit reports

Lifecycle automation, role modeling and certification at scale are typically handled by a dedicated identity governance product such as midPoint, which is a separate product decision with its own licensing, connectors and operating model. Separately, authentik does not issue audit reports, attestations or opinions. Independent auditors perform the testing under the PCAOB standards, so you should plan which governance tool, if any, you adopt and confirm early what evidence your auditors will request.

How the auditor's test of access controls works in practice

Under PCAOB AS 2201 paragraph 44, an auditor testing operating effectiveness asks two questions: does the control operate as designed, and does the person performing it have the necessary authority and competence. For authentik, the control is not the software alone. It is the joiner, mover and leaver process around it, with the authentik group membership, application assignment and deactivation steps as the parts the auditor will trace. Before the sample is pulled, the reader should write down who approves an access change, which group or application grants that access, and who in the identity team is allowed to make the change. Those answers form the control description the auditor will test against.

In practice, the auditor selects a sample of terminations or access review sign-offs and works backward from the population. For each leaver, they expect to see the HR or service desk ticket, the timing of the disablement in authentik, and evidence that sessions and application access were removed. For each periodic review, they expect the exported list of group members or application users, the reviewer's sign-off, and the resulting changes. Authentik's event log and the ticketing system need to share identifiers, such as the username and ticket number, so each sampled item can be matched in both. Confirm with your own administrators which authentik events and log retention settings apply to your deployment before you rely on them as evidence.

Sample sizes, the population definition and the conclusions belong to the external auditor, not to DeployOpen or authentik. The implementation work is to make the evidence repeatable: a documented control description, consistent identifiers and an export of access lists that a reviewer can sign. Ask your auditor early which populations and time periods they plan to test, and agree on the format of the evidence before the first assessment period begins. Any exception the auditor raises will be judged against the control as written, so the written control must match what the team actually does.

Questions buyers ask before hiring help with SOX access controls

What does DeployOpen do for SOX access controls and what does it leave to others?

DeployOpen plans, implements, configures, hardens, documents and supports authentik inside your own infrastructure, and prepares the systems, controls and evidence that your team and external auditors will test. It does not decide which controls are in scope for your ICFR assessment, does not issue audit reports or attestations, and does not certify that you comply with SOX. Management owns the control design and the assessment, and the external auditor performs the attestation under PCAOB AS 2201 where Section 404(b) applies. Agree the boundary in writing before work starts so both sides know which evidence DeployOpen delivers and which decisions remain with you.

Is the open-source edition of authentik enough for SOX access controls?

The open-source edition can cover single sign-on, provider configuration and core provisioning, but several capabilities auditors often ask about are listed as Enterprise features on the authentik pricing page. These include privileged access management, enhanced audit logging, password history and the Google Workspace and Entra ID integrations. Whether you need them depends on how your access reviews and privileged access are evidenced today. Confirm the feature list against your control design with the vendor, and check the license terms in the repository, since code in the enterprise directory falls under a separate license. Pricing for Enterprise is listed on the pricing page, so use that page as the starting reference for licensing cost.

What drives the cost of a SOX access controls engagement?

DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope with deliverables and timelines agreed in advance. The main cost drivers are the number of applications brought under central sign-on, the number of HR and directory sources, how many provisioning connections must be built, how many control owners must be trained, and how much evidence collection must be automated. Ask for a quote that separates one-time work such as design, build and testing from recurring work such as access review support, upgrades and retainers, and ask which items are optional. Licensing costs for authentik are a separate line and depend on your edition and user count.

How long does it take to get authentik ready for SOX access controls?

Duration depends mostly on the size of the application inventory, the quality of the HR source of truth, and how many systems in scope need changes to authentication or provisioning. Other drivers include whether the control design is already documented, how much testing the auditor expects to see, and how many change windows your organization allows. Your auditor's planning and your fiscal year-end also shape the schedule, because management must evaluate controls as of each fiscal year end under Rule 13a-15(c). Ask for a timeline in the written scope that lists the dependencies on your side, such as access to systems and approvals, rather than relying on a generic estimate.

What must our team provide before the engagement starts?

The engagement needs a complete application inventory with owners, classified by whether each system supports financial reporting. It also needs a named HR source for joiners, movers and leavers, and a list of control owners who will perform and sign off each review. Ask your external auditor which population, sample and evidence format they expect, because PCAOB AS 2201 tests focus on whether a control operates as designed and whether the person performing it has the necessary authority and competence. Provide read access to current access lists, the existing access review records, and the policy that defines privileged roles. Your team should also confirm change approval paths for the systems being connected.

Can our in-house team implement and run these controls without a partner?

Often yes, if your team already runs identity infrastructure and has people who understand ICFR. The work involves directory and provider configuration, provisioning connectors, role design that respects segregation of duties, and building repeatable evidence for reviews. PCAOB AS 2110 names access beyond what duties require as an IT risk that can break segregation of duties, so the role model needs to be reviewed independently of the people who built it. Compare your team's capacity and experience with the list of components above. Many organizations use a partner for the initial build and testing, then keep the controls operating internally. Either way, document who owns each control.

Can DeployOpen certify that our authentik controls meet SOX requirements?

No. DeployOpen cannot certify compliance and does not issue audit reports, attestations or certifications. Under SOX Section 404, management assesses internal control over financial reporting each year, and for accelerated and large accelerated filers that are not emerging growth companies, an independent auditor provides the attestation. DeployOpen prepares the configuration, documentation and evidence that support those assessments and testing. Ask your auditor early which evidence format they will accept and whether they will review the design before testing begins, so the work is aligned with what they will actually examine.

How DeployOpen scopes SOX access control work

Most DeployOpen work for SOX access controls is fixed-scope, and the written scope is where the audit-relevant decisions are made. Before implementation starts, the scope document should list every in-scope application and directory, the named control owner for each provisioning, removal and review control, the evidence each control will produce and where it will be stored, and the timeline for each phase. For an authentik deployment, that means naming which applications sign in through authentik, which groups grant access to financial systems, which provider types are involved (for example OAuth2/OIDC, SAML or LDAP), and who approves changes to those groups. Ask whether your external auditor has reviewed the proposed control list before the scope is signed.

The build then follows the agreed scope: configuration of applications, groups and access bindings in authentik, removal procedures tied to your leaver process, review exports and the runbooks your staff will use. Documentation and handover are part of the same written scope, so your control owners can perform and evidence the controls without DeployOpen involved. Confirm in the scope what format the handover documentation will take and who on your side will accept it.

Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope implementation. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports or attestations and cannot promise any audit outcome. Independent auditors decide whether controls operate effectively, so the scope should describe the evidence you will hand them, not the result you expect.

How DeployOpen delivers SOX-ready authentik configuration and evidence

DeployOpen plans, builds and documents authentik inside your own infrastructure, so access controls over financial applications and data are designed around your ICFR scope. We hand over the configuration and the evidence trail your management and external auditors will test, and we can support it afterward.

How we scope

Engagements are fixed-scope, with the in-scope financial applications, data stores and user populations agreed in writing before work starts.
Scope names the provisioning and removal sources, the access review owners and the privileged accounts that need separate controls.
Your auditors and internal audit should confirm which IT general control areas they expect you to evidence before scope is signed.

How we build

We configure authentik groups, roles and application access so each grant traces to a documented business owner and approval.
We set up privileged access with separate administrator accounts, and we test that event logging captures changes to those permissions.
We test joiner, mover and leaver scenarios in a non-production environment, then re-test the same scenarios after each change window.

How we hand over

Handover covers configuration documentation, runbooks for provisioning, removal and access review, and a written control narrative for each in-scope area.
We provide a sample evidence pack showing the exports, logs and approvals your control owners will retrieve for an auditor walkthrough.
Edition-dependent features such as enhanced audit logging should be confirmed against your license tier during scoping, before the evidence design is final.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so changes to authentik stay inside the documented control design.
Upgrade planning checks each authentik release against the access controls in scope before a version change reaches production.
Periodic re-testing of access removal and privileged access helps your team show operating effectiveness across the audit period.