How authentik supports NIST SP 800-53 IA-2 for your organization
authentik supports the technical implementation of IA-2 and its multi-factor authentication enhancements, but the control's organizational obligations and its assessment remain with your organization and your assessor. IA-2 asks the system to uniquely identify and authenticate organizational users and to tie that identity to the processes that act on their behalf. Under SP 800-53B Release 5.2.0, IA-2 is selected for the low, moderate and high baselines but not for the privacy baseline, so the baseline your system falls under determines how far the control reaches. Enhancements IA-2(1) and IA-2(2) require MFA for privileged and non-privileged accounts, and IA-2(8) and IA-2(12) add replay resistance and PIV credential acceptance at the baselines listed in the standard. IA-2(5), individual authentication with group authentication, applies only at the high baseline.
In practice, the first decision is which accounts in your environment count as privileged and which applications sit behind authentik. Each application should have its own authentik provider so that every sign-in is tied to a named user account, and shared or group logins should be reviewed against IA-2(5) if your system is high impact. Next, decide which authentication flows require a second factor for each group and application, and confirm in your own environment that MFA cannot be skipped through a fallback path. Confirm with your authentik edition which features you need, since the pricing page places certain capabilities, such as mTLS client certificate authentication, in the Enterprise edition, and PIV or hardware-based options should be checked against the version you deploy.
DeployOpen plans and implements the authentik configuration, prepares the system settings and evidence an assessor will examine, and documents how each IA-2 determination statement is addressed. DeployOpen does not issue audit reports or certifications. The assessment of IA-2 is performed against SP 800-53A Rev. 5, which lists examine, interview and test methods for the control, so expect reviewers to request the list of system accounts, the authentication configuration and related audit records. Start with the NIST CPRT entry for IA-02 and map your baseline before scoping the work.
Which IA requirements authentik addresses and how to configure them
This table maps the IA-2 requirement and the enhancements selected for the moderate and high baselines to the authentik capability that addresses each one, the configuration it needs and the points to confirm against the release you run. Use it as a configuration checklist that feeds your own control implementation statement. The main takeaway is that unique accounts and group-bound MFA are configurable, while PIV acceptance and MFA for some non-web protocols need confirmation before you rely on them.
| Requirement | How authentik addresses it | What to confirm before relying on it |
|---|---|---|
| IA-2 unique identification of organizational users | One account per person in authentik, sourced from your directory or created through enrollment. Disable shared login accounts and route automation through separately documented service identities. | Inventory of service identities and their owners, and how each one is tracked in your system account list. |
| IA-2(1) MFA for privileged accounts | Bind an authenticator stage to an administrator group through a policy on the login flow, so privileged sessions cannot complete without a second factor. | Which second factor types your edition offers, and that administrator access to the authentik console itself also enforces MFA. |
| IA-2(2) MFA for non-privileged accounts | Apply the same authenticator stage to application-level groups for OAuth2/OIDC, SAML and proxy providers, so standard users meet MFA at sign-in. | That every application provider is bound to the MFA policy, and that no application bypasses the flow through a separate path. |
| IA-2(5) Individual authentication with group authentication (high baseline) | Where a group credential is used for access, require an individual factor before group membership is evaluated, using policy bindings on the flow. | Whether any shared group credentials still exist, since assessors will test that the individual factor is enforced for each member. |
| IA-2(8) Replay-resistant access | WebAuthn-based authenticators can be offered as the second factor, which resist replay. Time-based one-time codes do not meet this enhancement on their own. | WebAuthn stage settings, including whether passkeys are allowed as the only factor, and the exact authenticator types your release supports. |
| IA-2(12) Acceptance of PIV credentials | No PIV or smart card login is documented in the sources reviewed for this page. The documented mTLS client certificate option is listed as Enterprise only. | Confirm with the vendor whether PIV certificates can be accepted, and plan a PIV-capable upstream identity provider if they cannot. |
| Non-web clients (LDAP, RADIUS, RAC) | Provider types exist for these protocols, but MFA prompts on LDAP and RADIUS clients depend on protocol design and the stages available. | How each LDAP, RADIUS or RAC client authenticates with MFA, and whether unsupported clients need a separate control. |
Evidence assessors examine for IA-2 in authentik
SP 800-53A lists examine, interview and test objects for IA-2, and each one maps to a place where authentik keeps information. The cards below show which artifact answers each object, where it lives in the deployment, and how to keep it so an assessor can sample it later.
List of system accounts
Assessors start with the list of system accounts and check that every account maps to one named person or defined non-person identity. In authentik, export the user list from the admin interface, including user type, status, and group membership, and compare it with the HR roster or the joiner and leaver records. Retain a dated export each quarter, because PostgreSQL holds the current state and an export is the only frozen copy. Flag shared or generic accounts before the assessor does.
Group and policy configuration
Assessors test whether multi-factor authentication is enforced for privileged and non-privileged accounts, so they will ask how the flows and policies are bound to applications and groups. Export the authentication flow bindings, the policy bindings on each application, and the groups that hold administrative roles. Store these exports in version control so changes carry an author and a date. A binding that exists only in the UI is hard to show as the control that was in force on a given day.
Event logs from the server and worker containers
The server container, which runs core and the embedded outpost, writes authentication events, and the worker container runs background tasks such as scheduled events and syncs. Assessors sample login and failed-login records to confirm that each event ties to a unique user. Forward container logs from both containers to your central log platform and set a retention period that matches your audit policy. Confirm that logs record the user identity, not only the application name.
Data held in PostgreSQL
The architecture places configuration and data, except uploaded files, in PostgreSQL, so that database is the system of record for accounts, groups, events and sessions. Assessors may ask for a point-in-time view of who held access, which requires backups that can be restored and queried. Document the backup schedule, test a restore into a separate environment, and record the restore result. If you run the bundled database for testing, plan a separately managed database before an assessment.
Interviews with administrators and operators
Interview objects include the personnel who operate the system, such as system and network administrators. Assessors will ask how they create accounts, reset authenticators, handle lockouts, and assign administrator roles, and whether their answers match the configuration. Prepare a short runbook that names each step and the authentik screen or API call used. Record who holds administrator rights in authentik and confirm that their answers match that list.
Documented process for unique identification
The test object for IA-2 is the organizational process for uniquely identifying and authenticating users, so assessors read the written procedure before they test it. The procedure should state how a unique username is assigned, how shared accounts are prohibited or exceptions approved, and how identities are linked to upstream sources. Keep the document under change control and tie each version to the authentik release in use. Check the release page before writing the procedure, since authentik versions are named by year and month.
How the authentik deployment architecture affects the evidence trail
For IA-2 evidence, the database is the record. A self-hosted authentik deployment has three runtime parts: a server container running core with an embedded outpost, a worker container that runs background tasks, and PostgreSQL, which stores all configuration and data except uploaded files. The users, groups, providers, flows, policies, MFA device registrations and the event log that assessors sample all live in that database. Before an assessment, confirm who owns PostgreSQL backups, how often they run, how long they are kept, and whether a restore has been tested against a copy of the event data. Retention of audit records is set by your own backup and log forwarding choices, so decide it in the design phase rather than when the auditor asks for records from last year.
The 2025.10 release changed the storage picture. According to the authentik 2025.10 release notes, authentik no longer uses Redis, and caching, tasks, sessions and WebSocket functions moved to PostgreSQL. The same notes warn of roughly 50% more PostgreSQL connections after upgrading. For an IA-2 evidence trail, this means session state and task queues now share the database that holds your identity records, so connection limits, pooling and database sizing are part of the access control design, not only an operations concern. Any pre-2025.10 runbook that assumes a Redis instance is out of date and should be reviewed before the next upgrade.
Deployment method sets how much of this you must build yourself. The authentik Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production, so it suits a pilot or a small user population where you accept the operational load of backups and restores on one host. The authentik Kubernetes guide installs with Helm, and its bundled PostgreSQL is intended for demonstration and test environments, so production clusters need a separately managed PostgreSQL with its own backup, high availability and access logging. Confirm with your assessor which database controls they will test, because the platform team and the database team may each hold part of the evidence.
What authentik does not cover for IA-2 and related controls
authentik can enforce unique sign-in and MFA for the applications it fronts, but several IA-2 related obligations sit with your organization, your credential authority or your program documentation. The cards below list those gaps so you can assign owners before an assessment starts, not during one.
Identity proofing and account issuance
authentik records who an account belongs to, but it does not verify a person's identity before the account is created. Your HR or registration process must define how identities are proven, who approves account creation and how sponsors request access. Check that enrollment flows only start from that approved process, and keep the approval record alongside the account.
Program documentation NIST expects you to tailor
SP 800-53 is a flexible catalog, and NIST expects each organization to tailor controls within its own risk management process. The identification and authentication policy, the authenticator standards and the assignment of control parameters are documents you write and approve. authentik configuration should be traced back to those documents, not treated as the policy itself.
Privileged account definition
IA-2(1) requires MFA for privileged accounts, but authentik does not decide which accounts are privileged. Your team must define the privileged roles, map them to authentik groups and applications, and confirm that policies bind MFA to those groups. Review the list whenever administrative roles change, because a missed group leaves an admin account on single-factor sign-in.
PIV credential issuance
IA-2(12) concerns accepting PIV credentials, which are issued by a credential authority outside authentik. If your environment relies on PIV or CAC cards, you need that authority, its issuance process and its certificate trust chain. Confirm with your credential authority and your authentik version whether the certificate-based sign-in path you plan is supported before you commit to it.
Enterprise-only features and FIPS
mTLS client certificate authentication and enhanced audit logging are listed as Enterprise edition features, not Open Source. FIPS compliance is listed only for Enterprise Plus, with FedRAMP requirements named as the reason. If your assessment depends on these capabilities, confirm the edition and license terms in writing before the design is final.
FedRAMP applicability
FedRAMP covers cloud products that handle federal information on behalf of an agency, and systems used only for one agency's operations on cloud infrastructure are out of scope unless offered as a shared service. Whether a self-hosted authentik deployment falls under FedRAMP therefore depends on your system boundary and service model. Get that determination from your authorizing official or FedRAMP advisor, not from this page.
Configuration sequence for an IA-2 assessment
This sequence takes an authentik deployment from confirmed control scope to a set of IA-2 evidence that an assessor can examine, interview against and test. Each step ends with an output that the next step depends on, so gaps surface before the assessment rather than during it.
Confirm the baseline and IA-2 selections
Before any configuration, the compliance lead and system owner confirm the impact level of the system and the control baseline it selects in SP 800-53B, including which IA-2 enhancements apply. Enhancements IA-2(1), IA-2(2), IA-2(8) and IA-2(12) are selected at the low, moderate and high baselines, and IA-2(5) at the high baseline only. Record the selections and any tailoring decisions in the system security plan. Done means every enhancement in scope has a named owner and a stated implementation approach.
Deploy on a supported authentik version
The platform team deploys authentik on a version that receives security fixes under the project's security policy, which lists 2026.5.x and 2026.8.x as supported at the time of writing. Confirm the current list on the security policy page before choosing a version, because support windows change. Record the exact version, the PostgreSQL version and the deployment method in the configuration baseline. Done means the running version matches a supported line and the baseline document reflects it.
Define identities and group structure
The identity owner defines how each person maps to one unique account, how privileged and non-privileged roles are represented as groups, and how shared or service accounts are kept distinct from people. Unique identification under IA-2 depends on this design, because every privileged action must trace to an individual. Document the naming rule, the group-to-role mapping and the rule for who may create accounts. Done means a test population can be created with unique usernames and each group maps to a documented role.
Configure MFA stages by privilege level
The identity engineer builds authentication flows with MFA stages bound to policies, so privileged accounts and non-privileged accounts receive different requirements. Bind the privileged-group policy to IA-2(1) and the general-user policy to IA-2(2), and test that each group is challenged as expected. Keep the flow definitions in version control so changes can be reviewed. Done means test accounts in each group complete the intended flow and a失败 attempt on the privileged flow is refused without a second factor.
Enforce replay-resistant authenticators
For IA-2(8), the identity engineer restricts the authenticator types allowed for privileged access to replay-resistant options and disables weaker factors for those groups. Confirm with the authentik documentation which authenticator types it supports for each protocol, because support differs between web sign-in and LDAP or RADIUS clients. Where a protocol cannot enforce the stronger factor, record the compensating control and the residual gap. Done means the allowed-factor list for privileged groups is documented and each exception has an approver.
Connect applications through supported providers
The application owners connect each in-scope application using a provider type that authentik documents, such as OAuth2/OIDC, SAML, LDAP, proxy or RADIUS, and bind each application to the MFA-enforcing flow. Applications that cannot use these providers need a documented exception and a plan. Test sign-in for one privileged and one non-privileged account per application. Done means every in-scope application appears in the inventory with its provider, bound flow and test result.
Enable and forward audit events
The operations team turns on event logging for authentication, failed logins, flow changes and group changes, then forwards those events to the central log platform outside the authentik host. Confirm retention with the log platform owner, since the retention period is set in that system and not in authentik. Generate test events and confirm they arrive with user identifiers attached. Done means a test sign-in, a failed attempt and a flow change each appear in the central log with a traceable account.
Rehearse the evidence pull
The compliance lead runs a dry-run of the evidence an assessor would request: the account list, group membership, flow configuration, MFA enrollment status for privileged accounts, and sample authentication logs. Map each artifact to the IA-2 determination statements and the examine, interview and test methods in SP 800-53A. Assign an owner to each artifact and fix any that cannot be produced within a normal working session. Done means each artifact is exported, labeled with the control it supports, and stored with the assessment file.
Questions buyers ask about IA-2 with authentik
What does an authentik IA-2 implementation cost and what drives the price?
The price follows from the written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of applications and identity sources to connect, the MFA design (which factors apply to privileged and non-privileged accounts, and whether any LDAP or RADIUS clients need a second factor), the number of deployment environments, and how much evidence must be built and documented for assessors. One-time costs cover design, build, integration and evidence preparation. Recurring costs cover upgrades, monitoring and support, which can be handled through a retainer. Ask for a quote that separates these items and lists the applications and sources in scope. Authentik licensing is a separate cost: the pricing page lists an Open Source edition at no license fee and an Enterprise edition at $5 per user per month billed annually plus $0.02 per external user per month, so confirm which features your design needs before you budget.
How long does a fixed-scope authentik engagement take?
Duration depends on the agreed scope, which is confirmed in writing before work starts, so no fixed duration applies to every engagement. The length is set mainly by the number of applications that need SSO or MFA, how many user populations and identity sources must be reconciled, whether privileged access needs separate handling, and how much assessment evidence must be produced. Environment readiness matters too: access to cloud accounts, DNS, certificates and the reverse proxy path can add time if they are not ready when the work starts. Ask for a timeline that lists milestones and the client decisions each milestone depends on.
What does our team need to provide for an authentik IA-2 build?
The client supplies the information and decisions that the design cannot make alone. Typically this includes:
- Identity sources, such as an existing directory, HR system or upstream identity provider, with access for read-only review.
- Named application owners who confirm each application's login method, user groups and privilege level.
- Baseline decisions, such as whether the system is treated as low, moderate or high impact under SP 800-53B, and which MFA factors your policy allows.
- Environment details: hosting platform, PostgreSQL arrangement, reverse proxy and network paths, and who holds administrative credentials.
- Access to your control owners and assessors so evidence requirements are agreed early.
Missing decisions in these areas are a common cause of delay, so confirm ownership before the schedule is set.
Can an internal team implement authentik for IA-2 without a partner?
Yes, an internal team can implement authentik for IA-2 if it has the skills and time. Authentik is self-hosted, and the Docker Compose guide positions Compose for test setups and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production. Internal teams typically need experience with identity protocols, reverse proxies, database operations and security assessment, plus a plan for upgrades and monitoring after go-live. Many organizations use a partner for the design, the evidence build or a limited review, and run day-to-day operations themselves. Assess your team's capacity against the scope list, and check whether the skills exist across identity, infrastructure and compliance.
Which authentik edition includes the features an IA-2 design needs?
The edition you need depends on which features your design uses. The Open Source edition is free and is covered by the MIT license for most of the code, but its support is community Discord only. The Enterprise edition, billed as listed on the pricing page, includes Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for subscriptions over $1k. Enterprise Plus adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Code in the enterprise directory falls under a separate license. Map each IA-2 requirement to the features it needs, then confirm edition availability on the authentik pricing page before you decide.
Does a DeployOpen engagement result in NIST SP 800-53 certification?
No. DeployOpen plans, implements, hardens and documents the systems, controls and evidence that support a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent assessors and the authorizing bodies that apply to your system make those determinations. NIST itself does not offer or endorse any compliance program or tool. The practical question is whether your assessor will accept the evidence, so agree the evidence list with them before implementation begins. Ask DeployOpen to show how each IA-2 determination statement maps to a configuration, a log source or a test result in your environment.
What to confirm with your assessor before you build
Agree the IA-2 determination statements and assessment methods with your assessor before you configure anything in authentik. IA-2 is assessed with two determination statements, using the examine, interview and test methods. The examine objects include the list of system accounts and system audit records, the interview objects include the personnel who run system operations and the system and network administrators, and the test objects include the organizational processes for uniquely identifying and authenticating users. Ask the assessor which evidence they expect for each object. A unique user identifier in authentik means little to an examiner unless you can show the account list, the group memberships behind privileged access and the audit records for logins. Settling that list early tells you which authentik exports, logs and screenshots you need to keep from day one.
Your baseline decides which enhancements apply. SP 800-53B selects IA-2 for the low, moderate and high baselines, but the enhancements change with the baseline. IA-2(1) and IA-2(2) require multi-factor authentication for privileged and non-privileged accounts at every impact level, while IA-2(5), individual authentication with group authentication, applies only in the high baseline. Confirm the impact level and baseline with your assessor and your authorizing official before you design authentication flows, since a moderate system may need MFA on all accounts and a high system may also need shared or group accounts handled under IA-2(5). Those decisions shape how you group users, which flows you enforce and what your access reviews must show.
Confirm which authentik edition and release line you will run, and which features that edition includes, before you write the design. The authentik pricing page separates the Open Source edition from the Enterprise and Enterprise Plus editions, and some capabilities you may want for audit evidence, such as enhanced audit logging, sit in the paid tiers. Check the pricing and provider documentation for each feature you rely on, and confirm that your chosen release line is still receiving security fixes according to the security policy. Also ask your assessor whether a FIPS compliance requirement applies, since the pricing page ties that to Enterprise Plus. Getting these answers in writing prevents a design that the assessor later rejects or that you cannot support.
How to scope an authentik IA engagement with DeployOpen
This sequence turns a control question into a written, fixed scope, a configured and evidenced authentik build, and a handover your team can run and audit after the engagement ends.
Define systems, applications and baseline in writing
Your team and DeployOpen list the systems and applications that authenticate through authentik, the user populations, the directories and sources in use, and the NIST SP 800-53 baseline (low, moderate or high) that applies to the system. Each IA-2 enhancement in scope, including MFA for privileged and non-privileged accounts, is named against a specific application or group. The step closes when the scope document is agreed and signed off by the system owner, with exclusions stated.
Confirm the authentik edition and version
DeployOpen checks which authentik edition is needed for each requirement in scope, since some capabilities such as mTLS client certificate authentication and password history are listed as Enterprise-only on the pricing page. The team also confirms the deployment target and the supported release line. The step closes with a written note of edition, version and any features that depend on a license decision your organization must make.
Build identity, MFA and authenticator configuration
DeployOpen configures user identification, enrollment, MFA stages, password and lockout policies, and provider settings for each application in the agreed scope, in the environment you control. Service and device identities are handled as separate accounts with documented ownership. The step closes when a test run shows each in-scope application requires the agreed factors and that unique identifiers are preserved in logs.
Map configuration to assessment objects
DeployOpen records how each configured control answers the determination statements for the IA-2 controls in scope, using the examine, interview and test objects that NIST lists for assessment. Evidence sources are named, such as account lists, audit records, configuration exports and procedures for user identification. The step closes with an evidence matrix that an assessor can follow without help from the build team.
Test authentication and evidence collection
DeployOpen runs documented tests for MFA enforcement, failed login handling, account disablement and audit event capture against the in-scope applications. Results, configuration exports and any defects are recorded with dates and the tester's name. The step closes when every test case in the scope has a recorded result and any open defects are assigned an owner in writing.
Hand over runbooks and evidence procedures
DeployOpen delivers operating runbooks for account lifecycle, authenticator reset, MFA device changes and log review, along with the evidence collection procedure that your staff will repeat for future assessments. Your administrators walk through the runbooks and perform one evidence pull under observation. The step closes when your named owners confirm they can run each procedure without DeployOpen.
Agree optional retainer support for upgrades
If you want ongoing help, the retainer scope is written separately and covers upgrades within supported authentik versions. DeployOpen reviews the security policy and release announcements, and checks that the authentik release line in use still receives security fixes before any change is scheduled. The step closes with a signed retainer scope or a documented decision to run the platform in-house.
How DeployOpen scopes, delivers and supports authentik compliance configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so authentik runs in your cloud accounts, data centers or air-gapped network. For NIST SP 800-53 identification and authentication, we turn the IA-2 requirement and its selected enhancements into written configuration, a test plan and an evidence set your assessors can examine. We prepare these systems and records for assessment but do not issue audit reports or certifications.
How we scope
- Confirm which systems, user populations and privileged accounts fall inside the authentication boundary for IA-2 and its enhancements.
- Record the authenticators in use today, including passwords, TOTP, hardware keys and service credentials, and which must change.
- Agree in writing which SP 800-53 baseline your system is assessed against, since low, moderate and high baselines select different enhancements.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts. Ongoing support is available as a retainer.
How we build
- Configure unique user identities, MFA stages and group-based policies in authentik, then test each one against the IA-2 determination statements.
- Set up separate, individually attributable accounts for administrators and service identities, and document how each is authenticated.
- Test MFA enforcement for privileged and non-privileged access, including failed-login and lockout behavior, with recorded results.
- Build the deployment on PostgreSQL and the chosen hosting model, with backups and configuration kept under version control.
How we hand over
- Deliver a control narrative mapping each IA-2 requirement and selected enhancement to the authentik settings that implement it.
- Provide an evidence pack listing configuration exports, flow and policy definitions, MFA test records and audit log samples for assessors.
- Document the open items, such as enhancements your baseline requires but your environment does not yet meet, with owners named.
- Run a handover session with the administrators who will operate the identity platform day to day.
How we support
- Review authentik security advisories and planned upgrades against the supported release lines, and agree a patch window with your team.
- Re-run identification and authentication tests after upgrades, new applications or changes to MFA policy.
- Refresh the evidence pack on a schedule you set, so assessment records match the configuration in production.
- Ongoing support, upgrades and continuous testing are available as retainers, with the scope confirmed in writing.
