How SOX authentication and password settings are tested
If a finance application, database or directory must hold up under a SOX 404 test, management has to show that sign-in settings are configured to a defined baseline and that those settings stay in place for the whole fiscal year. Auditors do not expect a specific password length or a named product. They expect the company to decide what authentication must look like for each in-scope system, to configure it that way, and to prove the configuration with system settings and records. The risk behind this is unauthorized access to data, which PCAOB AS 2110 lists as an IT risk to internal control over financial reporting. Weak or inconsistent sign-in settings let someone who should not hold an account change financial data without the application's own controls noticing.
There is no official ITGC catalog, so the baseline is the company's own. The usual starting point is to write down, for each in-scope application, database, operating system and directory, the minimum password length and complexity, lockout thresholds, session timeouts, whether single sign-on is used, and where multi-factor authentication is required, especially for remote and privileged sign-in. Management should then tie each setting to the financial reporting risk it addresses. Confirm with your external auditor which settings they expect to see inspected, because the scope of that inspection depends on the company's risk assessment and not on a generic list.
What makes this hard is usually not the setting itself but the spread of settings across layers. A finance application may defer to a directory, a database may keep its own password policy, and an operating system may enforce something different again. Legacy applications often cannot accept modern single sign-on, and service accounts tend to carry non-expiring passwords that no one reviews. Start by inventorying every authentication source for each in-scope system, then record the effective setting in each layer. Auditors inspect configuration exports and screenshots, so the evidence should show the live setting, the date it was captured and who approved the baseline.
Which systems and settings fall inside SOX authentication scope
Authentication scope starts with the financial systems that feed reported numbers, then extends down to the databases, operating systems, directories and sign-on services those systems depend on. The decisions below determine how far that boundary reaches and which settings management must be able to show.
Financially significant applications
Start with the applications that initiate, process or record transactions feeding the financial statements, such as the general ledger, subledgers, consolidation and reporting tools. For each one, record where users sign in, whether the application enforces its own password parameters, and whether it accepts local accounts alongside directory sign-in. Auditors will ask for the configuration as it exists in production, not as the policy describes it.
Underlying databases
Databases that store financial data often have their own accounts and authentication settings, and users can sometimes reach them without going through the application. Confirm which database logins exist, whether they authenticate against a central directory or local credentials, and how password and lockout parameters are set. Direct database access is a common path around application controls, so it belongs in the authentication inventory.
Operating systems hosting in-scope systems
Servers and workstations that host financial applications or databases need authentication settings that match the applications they support. Document how interactive logons are authenticated, whether local administrator accounts exist, and which password and lockout parameters apply. Where Linux or UNIX hosts join a central domain, verify that the join and the policy applied to it are what the configuration files show.
Directories and identity stores
The directory is often the single source of identity for many in-scope systems, so a weak setting there reaches every system that relies on it. List each directory that authenticates users to in-scope applications, its password and lockout policy, and who can change those settings. Changes to directory policy are themselves change-controlled events that auditors may request.
Single sign-on and identity providers
Where single sign-on or a federated identity provider sits in front of financial applications, that service becomes a key control point. Establish which applications trust it, how sessions are issued and ended, and who administers the provider. Confirm that disabling a user at the provider blocks access to every connected application, since the application-level setting may not be the one that governs sign-in.
Interactive versus service accounts
Interactive accounts are used by people and generally require multi-factor authentication and enforced password settings. Service and batch accounts run jobs and interfaces, often with non-expiring passwords, so they need a separate inventory with named owners and documented controls over who knows the credential. Auditors often find these accounts missing from the authentication population, so classify every account type before testing begins.
Provider-held settings in SaaS and cloud
When a SaaS vendor or cloud provider hosts a financial system, the password and multi-factor settings may be controlled by the provider rather than by the company. Ask whether the vendor's SOC report covers these settings, which ones the company must configure itself, and whether federation to the company's identity provider is available. Where the company cannot change a setting, the evidence it provides is the vendor's configuration output and the report, not a screenshot of an internal policy.
What auditors inspect in password parameters and MFA settings
An auditor testing authentication does not start with the screen. The auditor starts with the company's documented baseline, the written standard that states the minimum password length, complexity rules, lockout threshold, expiry period, session timeout and which systems must enforce multi-factor authentication (MFA) or single sign-on (SSO). The audit trail then moves from that baseline to the live system. For each in-scope application, database, operating system and directory, the auditor asks for the configuration file, the admin console export or the policy object, and compares each parameter against the baseline. Any gap, such as a lockout threshold set higher than the standard or an application that still accepts local logins without a second factor, becomes a finding that needs an explanation before the walkthrough closes. Confirm early which systems hold their own password policy and which inherit one from the directory, because the inherited ones are tested at the directory.
The test mix under PCAOB AS 2201 combines inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. For authentication, inquiry asks the security administrator who sets the policy and who can change it. Observation means watching a test user hit the lockout threshold or be prompted for a second factor. Inspection is the configuration export itself. Re-performance means the auditor, or the company on the auditor's behalf, attempts a non-compliant action and confirms the system rejects it. A screenshot from one date rarely proves that a setting operated across the audit period, so plan for configuration exports taken at intervals, change logs showing when a parameter was altered and an approval for each change. Ask your team whether the configuration history is retained by the platform or must be captured by a scheduled export, and confirm that the export itself is protected from edits.
How an assessor tests authentication settings
A design test asks whether the authentication baseline, taken on its own terms, would reduce the risk of unauthorized access to financially significant systems if it were operating as written. The assessor reads the standard, the policy and the configuration specification, then checks that someone with appropriate authority approved them before the period under audit. The baseline should address password length and complexity, lockout and session behavior, single sign-on scope, and where multi-factor authentication is required, including privileged and remote access. The assessor is looking for a documented decision, not a particular product setting.
- Approved baseline: a written standard with an owner, an approval date and a review cycle, signed by a party who is accountable for access risk.
- Coverage map: a list of in-scope applications, databases, operating systems and directories, each mapped to the baseline or to a documented alternative.
- Exception process: defined criteria, an approver and an expiry date for any deviation.
- Risk linkage: evidence that the baseline addresses unauthorized access, the IT risk that PCAOB AS 2110 names for financial reporting.
A common finding is a baseline that was approved for one platform but never extended to a newer system brought into scope. Confirm with your auditor how much design evidence they want for each in-scope system before the testing window opens.
An operating effectiveness test asks whether the settings stayed as approved for the full period. The assessor usually combines inquiry of administrators, observation of how settings are managed, inspection of change records and re-performance of a comparison between the approved baseline and the configuration at selected dates. Under PCAOB AS 2201, these methods are used together, so no single screenshot carries the test on its own. The period matters: a setting that was correct on the first day and changed in month six is a failure for the whole period unless the change was authorized and reviewed.
- Change evidence: tickets or pull requests for each authentication change, with approver, reason and implementation date.
- Configuration snapshots: dated exports or configuration-as-code history that show values across the period.
- Upgrade records: notes showing whether each platform upgrade was reviewed for changes to password, MFA or session defaults.
- Exception log: each deviation, its approval and its end date.
A frequent finding is drift after an upgrade. A new release changes a default, the change is not compared with the baseline, and the setting stays wrong for months. Ask the auditor how they will select dates and whether they expect snapshots at a fixed frequency.
System-level inspection is the direct review of live configuration. The assessor, or a person working with them, looks at the settings in the application, directory, database or operating system and compares them with the approved baseline. This is where the assessor checks whether the settings described in policy are the settings actually in force. Inspection also covers privileged and service accounts, which often sit outside the normal password policy and therefore deserve separate attention.
- Direct configuration review: screenshots, exports or read-only queries of password, lockout, session and MFA parameters.
- Enforcement path: confirmation that single sign-on routes users through the identity provider where the baseline requires it, and that local logins are disabled or limited as documented.
- Privileged account exceptions: a list of administrator, break-glass and service accounts with the reason each is exempt and who approved it.
- Consistency check: a comparison across environments so production, disaster recovery and test instances match where they should.
A common finding is an exemption that was never approved, such as a local administrator account that skips MFA because it was created during an outage. Before inspection, ask the auditor which screens, exports or commands they will accept as evidence.
Implementing authentication controls for an audit-ready baseline
This sequence moves authentication from an inventory of sign-in points to a documented baseline, configured identity services, controlled changes and periodic evidence of the settings auditors inspect. Each step names the artifact it produces so the file is ready for management testing and the external auditor's inspection.
Inventory in-scope authentication points
Management, with IT and the application owners, lists every application, database, operating system, directory and network device that authenticates users and that feeds financially significant reporting. For each one, record how users sign in (local accounts, directory, single sign-on, or shared credentials), who administers the setting, and whether the system is in SOX scope according to the scoping decision already made. Done means the inventory is reviewed and approved by the control owner, and every entry maps to a scoped system or a documented reason for exclusion.
Define the approved baseline per system
For each in-scope system, document the required authentication settings: password length and complexity, history, lockout thresholds, session timeouts, MFA requirements for administrators and remote access, and where the system delegates to a central identity provider. Set the baseline with the control owner and, where the system supports it, confirm each parameter by checking the vendor documentation or a test instance rather than assuming defaults. The output is a signed baseline per system with an owner and an approval date.
Configure the identity provider and directory
Implementation engineers configure the central services that the baseline depends on. authentik can act as the identity provider for applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it. FreeIPA can provide single sign-on for Linux and UNIX hosts through an MIT Kerberos KDC. Keycloak or Zitadel can enforce second factors, with Keycloak supporting passkeys, recovery codes and one-time password policies, and Zitadel offering Force MFA for all users or only locally authenticated users. Confirm each product's current capability against its documentation before committing to it in the design. Done means each in-scope system is tested against the baseline in a non-production environment and the test results are retained.
Enforce settings on production systems
Apply the tested configuration to production and disable any local accounts or bypass paths that the baseline does not permit, documenting the exceptions with compensating measures and an owner. Where a system cannot enforce a required parameter, record the gap, the risk it creates for financial reporting, and the interim control. Done means a production configuration snapshot is taken and compared against the signed baseline, with every difference either closed or formally accepted.
Lock configuration under change control
Bring authentication settings under the same change process used for other financially significant configurations. Any change to a password parameter, identity provider setting, MFA policy or directory trust needs a request, an approver who is independent of the administrator making the change, a test record and a rollback plan. Restrict who can edit these settings, and log the administrative actions. Done means the change ticket workflow is in place, administrator edit rights are limited to named roles, and a test change has been traced end to end from request to approval to deployment.
Export configuration snapshots on a schedule
Set up periodic exports of the authentication configuration from each identity provider, directory and in-scope system, stored in a location administrators cannot quietly overwrite. Name each export by system and date, and have a reviewer compare it to the approved baseline and to the change tickets for the period. Done means the first export is archived with a reviewer sign-off, and any unexplained difference is opened as an exception and tracked to resolution. The schedule itself should be documented so an auditor can see the cadence management chose and follow it.
Retain evidence for management and the auditor
Assemble the baseline, the test records, the change tickets, the snapshots and the exception log into one evidence package for each system. Management reviews the package and confirms the control operated throughout the period, and the external auditor selects samples to inspect the settings, re-perform comparisons and interview administrators. Ask your auditor which snapshot frequency and sample sizes they expect before the first period closes. The output is an organized, indexed evidence folder per in-scope system that someone outside the team can follow without help.
Evidence that passes authentication settings testing
What is the approved authentication baseline document and why do auditors ask for it?
The approved authentication baseline is a written standard that states the required password parameters, lockout behavior, session rules, single sign-on expectations and multi-factor requirements for each in-scope application, database, operating system and directory. Auditors ask for it first because it defines what the settings are tested against. Without an approved baseline, an auditor has no criteria to judge a configuration as correct, so the test cannot conclude. The document should name an owner, show an approval date and a version, and list the systems it covers. Keep it current by tying review to change control: when a platform is added, upgraded or its settings change, the baseline should be re-approved by the control owner. Management owns this document. An implementation partner can draft it from the platform's configuration options, but the organization must approve it.
What do configuration exports with dates prove to an auditor?
Configuration exports show the settings that were actually in effect on a given date, which lets an auditor compare reality against the approved baseline. For self-hosted platforms, the export can be a dumped configuration file, a policy report from the administration console, or the output of a command that reads realm, directory or policy settings. Each export should carry the system name, the date and time, the person or job that produced it and the hash or storage location that shows it was not edited. Keep exports in a locked evidence repository and produce them on a schedule, plus at each significant change. Auditors test the setting against the baseline, so exports should show the exact parameter names and values, not a summary. Confirm with the platform documentation which settings are exposed in exportable form, since not every parameter is available through the same interface.
How do MFA enrollment reports show that second factors are actually in use?
An MFA enrollment report lists which users or accounts have registered a second factor, which method they use and when they enrolled, so auditors can see that the policy reaches people rather than existing only on paper. A report that covers every user in scope, with exceptions listed separately, is far more persuasive than a statement that MFA is enabled. Useful fields include user identifier, factor type, enrollment date, last authentication date and whether the account is locally authenticated or federated. Accounts without a second factor need a documented reason and an approved exception. Generate the report from the identity system at regular intervals and reconcile it against the active user listing used in access reviews. Confirm with each platform how it records enrollment, because some store factor status differently for local and federated users.
What SSO integration records should be kept for in-scope applications?
SSO integration records show which in-scope applications delegate sign-in to a central identity provider, how that delegation is configured and who approved it. Auditors look for a list of applications mapped to their identity source, the protocol used (such as OpenID Connect, SAML or LDAP), the configuration of the trust relationship, and evidence that local password logins were disabled or restricted where the baseline requires it. For self-hosted identity platforms, such as authentik for OAuth2, OpenID Connect and SAML providers, or FreeIPA for Kerberos-based single sign-on on Linux and UNIX, the provider definitions and application bindings are the primary artifacts. Keep an inventory that is reviewed when applications are added or retired. Applications that still accept local credentials should appear on the exception register. Confirm each platform's supported protocols against its current documentation before relying on them as evidence.
How should exception approvals with expiry dates be documented?
An exception approval records a documented deviation from the authentication baseline, such as a legacy application that cannot enforce multi-factor authentication, together with who approved it, why, what compensating measures apply and when it expires. Auditors test exceptions for three things: that an authorized person approved the deviation, that the reason is valid and that the exception is not left open indefinitely. Each entry should have a unique reference, the affected system, the specific setting, the compensating control, an approver with appropriate authority, an approval date and an expiry date. The exception register should be reviewed on a set schedule, and expired items either closed or re-approved with fresh justification. Compensating controls such as network restriction or enhanced logging should be evidenced too. Management decides which exceptions to accept. An outside consultant can help structure the register, but cannot approve deviations on the organization's behalf.
Which change tickets prove that authentication setting changes were authorized?
Change tickets for authentication settings show that each change to a password parameter, MFA requirement, SSO binding or session rule was requested, approved, tested and recorded before it reached production. Auditors compare a sample of configuration changes against tickets to confirm that each change had an approval that predates implementation. A good ticket records the setting changed, the old and new values, the business reason, the approver, the test performed, the implementation date and the person who made the change. Changes made directly in an administration console without a ticket are a common finding, so administrators should be trained to route changes through the process. Keep the ticket linked to the configuration export taken after the change. Where the platform logs administrative actions, retain those logs alongside the tickets. Confirm with your change management tool whether it can link to identity platform audit records so the two can be reconciled.
How can an engineer keep this evidence current between audits?
Keep authentication evidence current by treating it as a recurring operational output rather than an annual project. The practical pattern is to schedule configuration exports and MFA enrollment reports, reconcile them against the approved baseline and the exception register, and file the results with dated, traceable records. Build alerts for drift, such as a password parameter changed outside a ticket or a new application created without an SSO binding. Review the baseline when platforms are upgraded, because defaults and available settings can change between versions. For interim testing, auditors often sample evidence from across the period, so a consistent naming and storage scheme matters more than volume. DeployOpen can plan, configure and document this evidence process for self-hosted platforms in the client's own environment under a fixed-scope agreement, and ongoing support or continuous testing is available as a retainer. Auditors, not DeployOpen, test the controls and issue any report.
What meeting authentication controls costs in money and effort
This table breaks down the cost components of meeting authentication controls for SOX in-scope systems, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to scope a quote and to see where self-hosted open-source identity platforms remove license spend but not configuration, evidence or testing effort.
| Cost component | One-time or recurring | Who is paid or who carries it | What drives it up or down |
|---|---|---|---|
| Identity platform licenses | Recurring | Commercial identity vendor, if one is used | Self-hosted open source such as authentik, FreeIPA, Keycloak or Zitadel avoids license fees, but confirm each platform's current license terms |
| Self-hosting infrastructure and operations | Recurring | Your cloud, data center or hosting team | High availability requirements, number of sign-in flows and whether the identity service is in SOX scope |
| Engineering time to configure password and MFA settings | One-time, with later changes | Internal platform team or implementation partner under a written scope | Number of in-scope applications, databases, operating systems and directories that each need their own settings |
| Integration of legacy and non-SSO applications | One-time, often the largest item | Internal engineers or implementation partner | Legacy applications with local accounts, unsupported protocols or hardcoded service credentials |
| SaaS and cloud integration work | One-time, then recurring as apps change | Internal administrators or implementation partner | Count of SaaS applications that feed financial data and whether they support SAML or OpenID Connect |
| Baseline and policy documentation | One-time, reviewed periodically | Internal compliance and security staff | Number of distinct password and MFA standards, and how many systems deviate from the baseline |
| Evidence collection and upkeep | Recurring, usually each audit period | Internal control owners, with optional tooling | Frequency of configuration changes, automated exports of settings, and how screenshots or config snapshots are retained |
| Readiness testing and external review | Periodic, optional | Independent assessor or consultant, selected by you | Scope size, prior deficiencies and whether testing covers every in-scope system or a sample |
| Auditor testing of system settings | Recurring, each audit cycle | External auditor, billed under its engagement terms | Number of in-scope systems, inspection depth and whether settings are provided in consistent, reproducible form |
Who owns authentication controls, and what a partner can prepare
Management owns the internal control over financial reporting, so the internal team owns the authentication baseline for in-scope applications, databases, operating systems and directories. That means deciding the required password parameters, whether single sign-on and multi-factor authentication apply to each system, and who may approve an exception. The baseline is a policy decision, not a configuration task, and it has to be approved and dated so an auditor can compare actual settings against it.
- Baseline ownership: Security or IT governance writes the standard that states required password length, complexity, lockout, history and session settings for each in-scope system.
- Approval records: Named approvers sign off on the baseline and on any change to it, and the approval date is retained.
- Exception handling: Each deviation, such as a legacy application that cannot enforce multi-factor authentication, needs a documented reason, a risk owner and a review date.
- Ongoing monitoring: Someone inside the company reviews configuration evidence on a defined cycle and follows up on drift.
- Accountability: Application owners confirm which systems fall inside scope and which settings their teams can change.
Before engaging anyone, confirm that the baseline, the approver list and the exception register already exist, because those documents are the first thing an auditor will ask for.
An implementation partner such as DeployOpen can configure and document the systems against the baseline the company has approved, and can prepare the evidence that shows the settings are in place. This work is delivered under a fixed written scope that names the systems, the settings, the deliverables and the timing. The partner does not decide the baseline, approve exceptions or attest to the result. Those remain with management and the independent auditor.
- Configuration work: Setting authentication parameters in self-hosted platforms such as authentik, FreeIPA, Keycloak or Zitadel, inside the client's own infrastructure.
- Integration: Connecting applications to a central identity provider so sign-in is delegated and multi-factor authentication is enforced consistently.
- Documentation: Writing configuration records, runbooks and change logs that map each setting to the approved baseline.
- Evidence preparation: Exporting configuration snapshots and logs in a form the internal team can hand to the auditor.
- Scope boundaries: Written deliverables that state what the partner will not do, including approving access or signing off on control effectiveness.
Ask the partner to show, in the written scope, which settings it will change and which artifacts it will hand over, so the company can later explain who did what.
The external auditor tests the controls under the PCAOB standards and forms the opinion on internal control over financial reporting. Under AS 2201, operating effectiveness testing combines inquiry, observation, inspection of documentation and re-performance. For authentication, that typically means inspecting configuration screens or exports, comparing them with the approved baseline and re-performing a sample of sign-in conditions. The auditor evaluates the control; it does not design or configure it.
- Inspection: The auditor reviews system settings, policy documents and the approval trail behind each parameter.
- Re-performance: The auditor may test a sign-in attempt or a password change to confirm the setting behaves as documented.
- Independence limits: An auditor that designs, builds or operates the authentication controls it later tests cannot be independent of them.
- Reliance on others' work: Where a partner or internal team produced the evidence, the auditor decides how much reliance to place on it after its own testing.
- Opinion: Only the independent auditor issues the attestation report.
Before fieldwork, confirm with the audit firm which evidence formats it accepts and how it wants independence safeguards documented for any outside implementation work.
Where authentication controls usually fail under SOX testing
Authentication settings are easy to configure and hard to prove. The gaps below recur because the settings live in several systems, change outside a single owner's view, and often lack evidence for the full audit period. Each card pairs a gap with the check that closes it.
Undocumented configuration baselines
Many teams cannot show what the approved password length, lockout threshold, session timeout or MFA rule should be for each in-scope system. Without a written baseline, an auditor has no standard to test the live setting against, and the control is hard to call designed effectively. Write a baseline per application, database, operating system and directory, name the owner, and tie it to the risk that authentication addresses, which PCAOB AS 2110 identifies as unauthorized access to data.
Settings that drift outside change control
An administrator can loosen a password policy or disable a second factor in a console, and the change never reaches a ticket. Auditors inspect current settings and compare them with the baseline, so a single untracked change can break an otherwise sound control. Export configurations on a schedule, compare them with the baseline, and route any difference through the program change process.
Shared and service accounts exempt from MFA
Service accounts, break-glass logins and shared administrator IDs are often excluded from MFA and password rules because they cannot easily prompt a person. Those accounts frequently hold the broadest access to financial data. Inventory every non-personal account, document why each is exempt, restrict its use to named owners, and compensate with vaulted credentials, rotation and logged use.
Orphaned local accounts that bypass SSO
Applications and databases often keep local user stores alongside the central identity provider. A local account can survive after the person leaves, sign in without MFA, and avoid the single sign-on logging that auditors use. Disable local sign-in where the product allows it, or force local accounts into the same policy, and reconcile local user lists against the HR-driven directory each period.
Force MFA settings left at defaults
Identity platforms expose options such as requiring a second factor for every user or only for locally authenticated users. A default that exempts some population can leave a gap no one notices until testing. Confirm in the vendor's documentation what each option enforces in your version, then capture a screenshot or export that shows the enforced setting, and test a sample login from an exempt-looking group.
No evidence from the period under audit
A setting that is correct today may have been different for most of the fiscal year, and an auditor tests operation across the period, not a snapshot. Teams often can only show the current state. Retain dated configuration exports, change records and access logs for the full period, and perform a roll-forward check so the evidence covers the dates the auditor selects.
Authentication settings questions buyers ask before hiring help
What does outside help for SOX authentication controls cost?
The cost depends on how many in-scope systems need authentication work, how much of their configuration is undocumented, and how much evidence the auditor will expect. No supplied figure sets a price for this work, so ask for a quote built from a written scope. Costs fall into three groups: the engagement itself (scoping, configuration review, remediation and evidence preparation), the internal time your team spends on approvals and walkthroughs, and recurring work each quarter or year to re-inspect settings. The external auditor's fees are separate and are set by the auditor, not by any implementation partner. Ask every bidder to price each system and each evidence package separately so you can compare scopes, not headline totals.
How long does it take to get authentication settings audit ready?
The timeline is set by the number of in-scope systems, the state of their current settings, and whether identity sources are already consolidated. Systems that rely on local accounts or inconsistent password rules usually take longer because each one needs a design decision and a change window. Build the schedule backward from your fiscal year end and your auditor's interim testing dates, and leave time for a full cycle of evidence collection, since auditors often inspect settings at a point in time and again later in the year. Any duration in a proposal should be tied to a written scope and milestones, not to a generic promise.
What must our company provide before an implementation partner starts?
Your company must provide access, decisions and documentation that only it can supply. Expect to provide:
- A current inventory of in-scope applications, databases, operating systems and directories, with the owner of each
- Read access to configuration exports or administrator consoles so settings can be inspected and recorded
- Your written password and multi-factor authentication standard, and the approvals that back it
- The identity provider and directory design, including where accounts are created and which systems use single sign-on
- A named owner who can approve changes and sign off on evidence
The partner prepares systems and evidence. Your organization still owns the controls and the decisions about them.
Can our internal IT team handle SOX authentication work without outside help?
Yes, many organizations do this work in-house, provided the team understands the control objective, can explain each setting to an auditor, and has the time to keep evidence current. The usual gaps are not technical. They are documentation, consistent settings across systems, and a repeatable way to show that settings were the same at the test date. Outside help is most useful when the environment is fragmented, when several systems need configuration changes at once, or when the internal team has no one who has walked an auditor through an ITGC test before. Compare the cost of that help with the internal hours it would replace, and check whether a co-sourced arrangement would fit your audit plan.
What will an external auditor do and what will it not do for us?
An external auditor tests the controls under PCAOB AS 2201 by combining inquiry, observation, inspection of documentation and re-performance. For authentication, that typically means inspecting configured password parameters, reviewing single sign-on and multi-factor settings, and checking whether changes to them were approved. An auditor will not design or configure your controls, will not prepare your evidence, and will not issue a report based on work it did not perform. Under the same standards, an auditor must also keep its independence from the people who implement the controls. Ask your implementation partner to state in writing which tasks it performs, and make sure management, not the partner, signs off on the control descriptions.
Are open-source authentication platforms acceptable evidence for a SOX audit?
The platform itself is not the evidence. What the auditor needs is proof that the configured settings meet your policy, that they were approved, and that they stayed in place during the audit period. Open-source identity platforms can produce that evidence when their settings can be exported, reviewed and logged. Options such as authentik, FreeIPA, Keycloak and Zitadel each provide identity features like single sign-on, multi-factor authentication and password or one-time password policies, and each has its own configuration model. Confirm with your auditor which exports, change logs and screenshots it will accept, and confirm with the vendor or project which settings can be read back and which must be documented manually.
What risks do weak authentication settings create for a SOX audit?
Weak or inconsistent authentication settings create a path for unauthorized access to financial data, which PCAOB AS 2110 identifies as an IT risk to internal control over financial reporting. If an auditor finds that password rules differ across financially significant systems, or that multi-factor authentication is missing for administrators, it may conclude that the related control does not operate effectively. That can lead to a deficiency, and a severe one can become a material weakness. Ask any partner how it will document the risk, which systems it will prioritize, and how remediation will be tracked before year end.
Primary sources for SOX authentication requirements
Start with the primary texts before relying on any consultant summary. SEC Release 33-8810 is the management guidance that explains how to scope IT general controls for an ICFR evaluation. It says the relevant IT general control aspects vary with each company's facts and circumstances, and it asks management to evaluate only the controls needed for the proper and consistent operation of controls that address financial reporting risks. Read its discussion of IT general controls closely, then document why authentication on each in-scope application, database, operating system and directory is or is not part of that set. The SEC's Release 33-8810 is the document an assessor will hold you to.
The two PCAOB standards show what the external auditor will test. AS 2201, filed with the SEC as Release 34-55876, governs the audit of ICFR and describes how operating effectiveness is tested through inquiry, observation, inspection of documentation and re-performance. Its tests of authentication settings will usually take the form of inspecting configuration screens and re-performing the setting check, so your evidence needs to show the current configuration and when it last changed. AS 2110, filed as Release 34-62919, is the risk assessment standard. Its appendix on IT risks names unauthorized access to data as an IT risk to ICFR, which is the reason password parameters, single sign-on and multi-factor settings appear in auditor scoping. Confirm which version of each standard applies to your fiscal year, since the auditor will reference the current numbering. Read the PCAOB Auditing Standard No. 5 filing and the PCAOB risk assessment filing alongside your scoping memo.
The statute itself is the anchor for the rest. Section 404 of the Sarbanes-Oxley Act, codified at 15 U.S.C. 7262, requires management's annual assessment of ICFR and, for filers covered by the auditor attestation requirement, the auditor's attestation. Read the statute to confirm which filer category your company falls into, because that determines whether the auditor attestation applies at all. Then use the statutory text on GovInfo to frame the management assessment you will document for authentication. Ask your auditor which passages they will use to set the scope of authentication testing, and record their answer in the scoping file.
How DeployOpen prepares authentication evidence for SOX
The sequence below turns authentication settings on in-scope systems into a documented baseline and a set of exports an external auditor can inspect. DeployOpen prepares the systems and evidence, while the organization owns its controls and the independent auditor forms any opinion.
Agree the written scope of in-scope systems
DeployOpen and the client's finance, IT and internal audit leads list the applications, databases, operating systems and directories that feed financially significant reports, and the authentication points each one uses. The scope, deliverables and timeline are fixed in writing before work starts. The step closes when the client signs off a scope list that names each system and its sign-in path.
Document current authentication settings
DeployOpen collects the existing password parameters, single sign-on configuration and multi-factor authentication status on each in-scope system, working with the client's administrators inside the client's own environment. Gaps between the current state and the client's written policy are recorded rather than silently corrected. The step closes when a current-state inventory exists for every system in scope.
Deploy the self-hosted identity platform
Where the client chooses a self-hosted identity provider, DeployOpen installs and configures it in the client's cloud accounts, data centers or private networks. Options such as authentik, FreeIPA or Keycloak are matched to the systems in scope, and the client confirms each platform's capabilities against current vendor documentation before relying on them. The step closes when the platform runs in the client's environment and test sign-ins succeed.
Connect applications and enforce settings
DeployOpen points each in-scope application, database or directory at the identity platform and applies the agreed password parameters, single sign-on and multi-factor settings, such as TOTP, passkeys or security keys where the platform supports them. Local accounts that bypass the central provider are identified and either disabled or documented as exceptions. The step closes when each in-scope system reports the configuration that matches the written baseline.
Write the authentication baseline
DeployOpen drafts a baseline document for each system that records the approved settings, the configuration keys or console paths where they live, the owner of each setting and the change approval that governs it. The client's control owners review and approve the baseline, which the organization adopts as its own control design. The step closes when the signed baseline is stored with the client's policy documents.
Export configuration and access evidence
DeployOpen produces dated exports of the live settings, such as configuration files, policy screenshots, directory attribute reports and enrollment listings for multi-factor authentication, and stores them in a location the client controls. Each export is labeled with the system, the date and the person who ran it so that an auditor can inspect it. The step closes when an evidence index maps each baseline setting to at least one export.
Hand over to the auditor and the control owners
The client gives the evidence index and exports to its internal audit team and to the external auditor, who decides which tests to perform, including inspection of settings and re-performance where appropriate. DeployOpen answers questions about how the systems were configured but does not issue audit reports, opinions or attestations. The step closes when the organization's control owners confirm the evidence is complete and any auditor questions are logged for follow-up.
