Where authentik fits in an ISO 27001 secure authentication control set
authentik can supply the technical side of ISO/IEC 27001:2022 controls A.8.5 secure authentication, A.5.17 authentication information and A.5.18 access rights for applications you host yourself, but it does not satisfy them on its own. DeployOpen plans, configures and documents the platform and prepares the evidence an assessment will ask for, but DeployOpen does not issue audit reports or certifications. ISO itself does not certify organizations; accredited certification bodies do, and they audit your management system against the standard's requirements. The standard sets what must be achieved, while authentik provides configuration, enforcement points and logs that you can show an auditor.
The decisions that remain with your organization are policy, process and people decisions. Your topic-specific access control policy must define who may be granted which access, how authentication information is issued, reset and handled, and which systems must use single sign-on and multi-factor authentication. Your processes must cover joiner, mover and leaver steps, periodic access reviews and the approval trail behind each change. Your people must own those approvals, and staff must be advised on handling passwords and second factors, which is the advice A.5.17 expects. Confirm each of these owners in writing before configuring anything in authentik.
Treat authentik as the place where those decisions are enforced and recorded. Before an audit, confirm with your certification body which evidence they will sample, such as policy documents, group membership exports, flow and policy settings, and authentication event logs, and confirm which of these your deployment version can produce. Check the version against the authentik security policy and release notes, because only supported versions receive security fixes. Where a capability you need, such as password history or enhanced audit logging, is listed as an enterprise feature, confirm with the vendor whether your edition includes it before you rely on it in the control design.
Mapping A.8.5, A.5.17 and A.5.18 to authentik configuration
This table pairs each relevant ISO/IEC 27001:2022 Annex A control with what authentik can contribute and what your organization must configure and document. Read each row as a split of responsibility: authentik enforces settings you define, while policy, role design and review evidence remain your obligations. Confirm each capability against the authentik version you run, since the supplied facts do not confirm every feature in every edition.
| Control | authentik capability | Configuration the organization must set |
|---|---|---|
| A.8.5 Secure authentication (requirement: secure authentication technologies and procedures based on information access restrictions and the access control policy) | Centralized sign-in through OAuth2/OIDC, SAML and LDAP providers, with flows and policies that decide how users authenticate to each application. MFA stages can be bound to flows, subject to confirmation in your version. | Write an access control policy that names which applications need MFA and which may use single factor access. Bind authentication flows to applications by risk tier, and document the mapping. Confirm which MFA methods your edition supports before setting the policy. |
| A.8.5 cross-reference (NIST crosswalk to AC-7, AC-8, AC-9 and IA-6) | Failed sign-in handling, use notification, previous logon notification and authentication feedback are related areas. Confirm whether your authentik version provides lockout, banner and last-login display options. | Set failed attempt thresholds and lockout behavior in policy, and record the chosen values. NIST cautions that mapped controls are not always equivalent, so treat this as a reference point and validate against the ISO control text with your auditor. |
| A.5.17 Authentication information (requirement: management process for allocating and managing authentication information, with advice to personnel on handling) | Password rules and password change flows are enforced through authentik policies. Password history is listed as an Enterprise feature on the pricing page. Authentication information for service accounts can be managed through the same identity store. | Define a documented management process covering enrollment, reset, recovery and expiry of credentials. Set password policy values in authentik and record them. If password history matters to your policy, the Enterprise edition is required per the pricing page. Write and deliver staff guidance on handling credentials. |
| A.5.17 (MFA and factor enrollment) | Second factors are enrolled and managed per user within authentik. Enrollment and recovery flows control how factors are issued and reset. Confirm which factor types and recovery options your version offers. | Specify who approves factor resets and how identity is verified before a reset. Retain records of factor enrollment and reset events. Document the procedure for lost or compromised factors. |
| A.5.17 (privileged and shared credentials) | Groups and application access bindings separate administrative sign-in from standard use. Enterprise privileged access management is listed on the pricing page, and its scope should be confirmed before you rely on it. | Use separate administrative accounts and groups for privileged roles. Decide which shared or break-glass credentials exist outside authentik, and where they are stored and reviewed. |
| A.5.18 Access rights (requirement: provision, review, modify and remove access rights per the access control policy) | Groups, application bindings and policies control who reaches each application. Provider types cover OAuth2/OIDC, SAML, LDAP, proxy and SCIM, which can carry group membership to connected systems. Confirm provisioning scope for each target. | Design roles as groups mapped to job functions, and bind each application to the groups allowed to use it. Document who approves each grant, and how changes are requested and recorded. |
| A.5.18 (access reviews) | authentik lets administrators list group memberships and application bindings for review. Event logs record changes, and enhanced audit logging is listed as an Enterprise feature on the pricing page. | Schedule periodic reviews of group membership and application access, with a named reviewer for each application. Keep the reviewed lists, the reviewer decisions and the resulting changes as evidence. Confirm your log retention and export settings. |
| A.5.18 (removal and leaver handling) | Disabling or removing a user and removing group membership cuts access across bound applications. Removal propagation to downstream systems depends on the provider type and any SCIM configuration in use. | Define a removal timeline and owner for leavers and role changes, and test that a disabled user cannot sign in to each application. Record removal tickets and the time each change took effect. |
Evidence an auditor will sample and how to keep it
An auditor testing A.8.5, A.5.17 and A.5.18 will sample records, not configuration screens. The cards below cover the evidence types that show authentication and access rights were operated over time, and each one needs a named owner in your ISMS process.
Event and audit logs
Authentication events, failed logons, MFA challenges and administrative changes in authentik are the primary proof that secure log-on procedures operated. Confirm which logs your edition retains, because enhanced audit logging is listed as an Enterprise feature on the pricing page. Also confirm how logs are forwarded off the server, how long they are kept and who can alter or delete them.
Provider and application configuration exports
Exports of providers, applications, flows and policies show what authentication rules were in force on a given date. Store them under version control with change dates, so an auditor can compare the setting sampled with the one approved. Providers include OAuth2/OIDC, SAML and LDAP, and each needs its own export.
Access review records
Periodic reviews of who holds which group membership and application access are the evidence for A.5.18. Record the reviewer, the population reviewed, the decisions taken and the removals made. The owner is usually the application or data owner, with the ISMS process owner approving the review cycle.
MFA and password policy documentation
Keep the approved password and MFA requirements alongside the flow and policy settings that enforce them. Auditors test whether the stated rule matches the running configuration, so record each change with its approval. Password history is an Enterprise feature, so confirm whether your edition enforces it or whether the rule must be covered by a documented procedure.
Joiner and leaver tickets
Each account creation, access grant, and removal should trace to a ticket that names the requester, approver and effective date. Auditors sample leavers to check that access was removed in time. Connect these tickets to the HR or identity process owner, since authentik only shows what happened, not who authorized it.
Upgrade and change records
Version upgrades change authentication behavior, so each upgrade needs a change record with the target version, the test results and the rollback plan. Check the security policy for which versions receive fixes and the advance notice given for security releases. Assign the change record to the platform owner and the approval to the change board.
How authentik flows and policies enforce password and MFA rules
The topic-specific access control policy comes first, and the authentik configuration should be traceable back to it. Before anyone opens the admin interface, the organization needs written rules for who may authenticate to which systems, what strength of authentication each class of access requires, and how accounts are enrolled and recovered. Under A.5.18 Access rights and A.8.5 Secure authentication, each login rule in authentik should point to a line in that policy. Without that link, an auditor sampling a flow cannot tell whether it reflects a decision or an accident of configuration.
In authentik, login, enrollment and recovery are built from *flows*, which are ordered sequences of *stages* such as identification, password, and authenticator validation. *Policies* attached to a flow or stage decide whether a given user or application passes through a step, so an MFA requirement can be bound to a group or to an application rather than to the whole tenant. A typical design for an illustrative workforce tenant might require a second factor for members of an administrators group on every application, while standard staff get it only on externally reachable applications. Confirm in your deployed version how bindings are evaluated and in what order, because the ordering determines which rule actually wins.
Password rules and the choice of second factors are covered on separate pages, and their settings differ between releases, so confirm them against the version you deploy before writing them into the policy. Also confirm which recovery and enrollment flows are enabled, and who can start them, since a recovery path that skips MFA can undo an otherwise strong login design. Keep the exported flow and policy definitions under change control so that each approved change to the access control policy has a matching change record and can be shown during an access review.
Configuration sequence for an ISO 27001 authentication control set
This sequence turns an authentication and access rights policy into a running authentik configuration, with each step leaving evidence that maps to A.5.17, A.5.18 and A.8.5. It is written so the control owner can show an auditor how policy, configuration, logs and reviews connect.
Confirm the access control and authentication policies
The control owner and information security lead document the topic-specific access control policy and the rules for authentication information, including password expectations, MFA requirements by information classification and how personnel are advised to handle credentials. This is the baseline every later setting is traced back to. Done means a approved policy version exists, names its owner and date, and lists which systems fall under it. Ask your certification body which policy wording and version they expect to sample.
Deploy authentik on a supported version
The platform team deploys authentik in infrastructure you control, using the Docker Compose or Kubernetes guide as the starting point. authentik's security policy lists 2026.5.x and 2026.8.x as the supported lines receiving security fixes, so the installed version should sit on one of them. Production deployments should use a separately managed PostgreSQL rather than the bundled test database. Done means the version is recorded in the change register and the instance is reachable only through the intended reverse proxy.
Design groups and roles from information classifications
The identity owner creates groups and role assignments that mirror the information classification scheme, so that access follows from classification rather than from individual requests. Each group gets a named business owner and a documented purpose, and privileged administrative groups are kept separate from everyday user groups. Done means a role matrix links every group to the applications and data classes it can reach, and the matrix is approved before any user is migrated into it.
Set MFA and password rules per group
The identity owner applies authentication flows and policies per group so that MFA strength and password rules follow the classification in the policy. authentik's enterprise edition lists password history as an enterprise-only feature, so confirm with the vendor whether your chosen edition provides it before relying on it as evidence. Done means a test account from each group is walked through enrollment and login, and the observed MFA prompt and password rules match the written policy.
Connect applications over OIDC or SAML
The application owners register each in-scope application as an OIDC or SAML provider and bind it to the groups from the role matrix, so access is granted only through authentik. Local accounts in each application are reviewed and disabled or documented where the application cannot be fully federated. Done means every in-scope application has a recorded provider, a bound group list and a test showing that a user outside the bound groups is refused.
Configure logging and forward events
The operations team enables authentication and administrative event logging and forwards those events to the central log platform, with retention set by the policy. Log entries for logons, failed attempts, MFA events and group changes are the evidence an auditor will sample. Done means test logons and a test group change appear in the central platform with timestamps and the acting identity, and the retention setting is written into the control record.
Patch on the security release cycle
The platform team subscribes to authentik release announcements and treats security releases as scheduled changes. The project announces security releases at least 24 hours in advance, so the change process should be able to start a patch window at short notice. Done means the patch procedure is written, the most recent version applied is logged, and the team can show when the instance was last moved to a supported line.
Schedule access reviews with documented outcomes
The control owner runs access reviews at a frequency set in the policy, comparing group membership and application bindings with the role matrix and HR records. Each removal, change or retained exception is recorded with the reviewer, the date and the reason. Done means a signed review record exists for the period, every change traces to a ticket or log entry, and open exceptions have an owner and a closing action.
Questions buyers ask before hiring help for ISO 27001 authentication controls
Does installing authentik make my organization ISO 27001 certified?
No. authentik is software, and it cannot make an organization certified. ISO does not certify organizations, and accredited certification bodies assess whether your information security management system meets the requirements of ISO/IEC 27001:2022. authentik can support the technical side of controls such as A.8.5 Secure authentication, A.5.17 Authentication information and A.5.18 Access rights by enforcing sign-in policies, MFA and role assignments and by producing logs. Your policies, risk treatment, roles, reviews and records are what the auditor samples. Treat the platform as one input to your ISMS, not as the certificate.
How much does an ISO 27001 authentication implementation cost?
DeployOpen does not publish a price list. A quote follows from a written scope, and the main cost drivers are the number of applications to integrate, the number of identity sources to connect, how many user populations and roles need separate treatment, the depth of evidence design (which logs, reviews and sign-offs must be retained and in what form) and the state of your existing environment. Costs fall into one-time work such as design, configuration, testing and documentation, and recurring work such as access reviews, upgrades and support if you choose a retainer. Ask any provider for a quote that separates these items, names the applications in scope and states what the client must supply. The authentik Enterprise features, such as mTLS client certificate authentication and password history, are licensed separately from the open-source edition, so ask for those to be itemized if you need them.
How long does an ISO 27001 access control project take?
There is no fixed duration. The time depends on the agreed scope, the number of applications and identity sources, the readiness of your policies and the infrastructure you will run authentik on. Most engagements are fixed-scope, so the timeline is agreed in writing before work starts. Ask for the phases, the dependencies on your team (policy approvals, change windows, application owner availability) and the review points where you sign off. A narrow scope covering one or two applications will move faster than a project that also redesigns role models and access review processes across the organization.
What does my team need to provide for an authentik engagement?
The work needs named people on your side from the start. Policy owners must approve password, MFA and session rules and the topic-specific access control policy that A.5.18 refers to. Application owners must confirm which users and roles should reach each system and test sign-in after integration. Your infrastructure team must provide hosts or cloud accounts, database services, DNS, certificates and network access. Someone accountable must sign off access reviews and the records they produce. Confirm these owners, their time commitments and their approval paths in the written scope so that delays are visible early.
Can our own team implement authentik controls for ISO 27001 without a partner?
Yes, a capable internal team can implement and operate the controls, provided ownership is defined. Assign one owner for the authentication policy, one for role design and provisioning, one for application integrations, one for logs and monitoring and one for periodic access reviews. Confirm that someone can run upgrades, since authentik releases are named by year and month and the security policy lists the supported versions. A partner is most useful when the team lacks time, when the scope spans many applications or when the evidence design needs an outside check before the certification body visits. Decide this by comparing your staffing against the owner list above.
Which ISO/IEC 27001 transition dates matter for an organization now?
Two dates matter most. Under IAF MD 26:2023, all certifications to the 2013 edition had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period, so organizations certified to the 2013 edition need to be certified to the 2022 edition. Separately, IAF MD 29:2024 required accredited certification bodies to apply ISO/IEC 27006-1:2024 to all clients by 31 March 2026, alongside ISO/IEC 17021-1:2015. Confirm with your certification body which edition and audit approach apply to your next audit, and map your authentication controls to the 2022 Annex A numbering so that your evidence references are current.
What should I check in an authentik deployment before an ISO 27001 audit?
Check that MFA and password policies are enforced by the flows and policies you documented, that privileged and administrative accounts are separated from everyday accounts and that access to each in-scope application traces back to an approved role. Confirm that event logs for sign-ins, failures and administrative changes are retained and forwarded to a location your team controls. Verify that a dated access review has been performed, that leavers are removed and that you can explain any exceptions. Confirm the authentik version you run is one that receives security fixes according to the project's security policy, and record the upgrade decisions you make.
Does DeployOpen guarantee that an audit will pass?
DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make the decision. DeployOpen plans and implements the authentication configuration, documents it, and can help you assemble the evidence an auditor will sample. Ask any provider to describe which parts of the work are their deliverables and which decisions remain with your management and the certification body.
What authentik does not cover for ISO 27001
authentik can enforce and evidence authentication and access rights for the systems it sits in front of, but it is one control source inside a wider ISMS. The cards below set out what remains with your organization, your auditors and your application owners, so the gaps are planned rather than discovered at audit time.
The ISMS itself
The management system is a set of organizational processes: defining the scope, running the information security risk assessment, approving policies and holding management reviews. authentik has no role in deciding which systems fall inside the scope or which risks justify a password or MFA rule. Your policy owners must write the topic-specific access control policy that A.8.5, A.5.17 and A.5.18 refer to, and then configure authentik to match it. Confirm who signs that policy and where the review record lives.
HR and joiner-mover-leaver processes
authentik can create, change and disable accounts once someone tells it to, but it does not know who has been hired, transferred or dismissed. The authoritative trigger usually sits in an HR system or a request workflow outside the identity provider. Until that trigger is defined, leavers can keep access to applications that were never connected to authentik. Document the source of each lifecycle event and who approves it.
Endpoint and device controls
Passwords and MFA prove that a person or service signed in, but they do not show that the laptop or phone used was patched, encrypted or managed. authentik does not inspect device posture unless you build that check into a flow or use a separate endpoint management product. A.8.5 covers the authentication technology itself, so device hygiene needs its own control owner and evidence. Ask which endpoint controls your auditor will expect alongside authentication.
The certification audit and its findings
authentik can supply logs, configuration exports and policy records that auditors sample. It does not issue audit reports or certificates, and it cannot decide whether a nonconformity is raised. Certification is granted by an accredited certification body under ISO/IEC 17021-1, which also requires at least one audit in every calendar year of the cycle. Plan evidence retention and sampling reports with your certification body before the audit starts.
Enterprise licensing and FIPS options
Several controls you may want to show, including password history, enhanced audit logging, mTLS client certificate authentication and privileged access management, are listed as Enterprise features on the pricing page. FIPS compliance and dedicated support with SLAs are Enterprise Plus options. Your mapping must name the edition you run, because a Open Source deployment may not contain the evidence a control relies on. Confirm edition and feature availability in writing before you design the evidence set.
Per-application capability checks
Each application connected to authentik must support the protocol, MFA enforcement and session behavior you rely on. Some applications accept SSO but keep local passwords, or ignore group claims for authorization. authentik cannot make a legacy application enforce its own roles. Test every connected application against the access rights and authentication rules you have documented, and record any gap as a risk with an owner. NIST's crosswalk links A.8.5 to controls such as AC-7 and IA-6, but NIST cautions that mapped controls are not always equivalent to ISO controls, so treat the mapping as a starting point rather than proof.
How auditors sample access rights and what to prepare
Auditors testing A.5.18 Access rights and A.8.5 Secure authentication usually start from a population, not from a single example. The population list is the complete set of accounts, group memberships and application assignments in scope for the period under review, exported from authentik with timestamps. From that list, the auditor selects a sample of users, applications and time periods, then asks for evidence that each sampled grant was approved, matched the role design, was reviewed on schedule and was changed or removed when it should have been. Prepare the export before the request arrives, and confirm with your certification body how it wants the population defined, including whether service accounts and outpost bindings are in or out.
For each sampled item, keep the evidence that links a person or account to an authentik group, the application provider that group reaches, the approval record, and the review decision with its reviewer and date. Authentik's event log can show logins, policy outcomes and administrative changes, but it does not record your approval decision, so that record has to live in your ticketing or access review tool. Also confirm which audit log events your plan includes. Enhanced audit logging is listed as an enterprise-only feature on the pricing page, so check whether your edition captures the events your sample will need before you commit to a log retention design.
Document every exception with its cause, the compensating step taken, and the date it was closed. Typical exceptions include a leaver whose account stayed active past the removal date, a group that inherited access nobody reviewed, or a password or MFA setting that was changed without a record. Auditors treat an exception with a clear, time-bound corrective action very differently from one that was never noticed. Ask your certification body how it expects exceptions to be recorded in the sample, what evidence it accepts for corrective actions, and whether it will review the population list before selecting items.
How DeployOpen scopes and delivers ISO 27001 authentication evidence
DeployOpen plans and builds the authentik configuration that supports A.8.5, A.5.17 and A.5.18 inside infrastructure you control, then documents the controls and evidence your team needs for its own ISO 27001 work. DeployOpen prepares systems, controls and evidence for assessment, but independent certification bodies perform the certification audit.
How we scope
- We agree a written scope listing which applications, user groups and authentication paths authentik will cover before work starts.
- The scope names the password, MFA and session policies to be configured, and the Enterprise-only features your team needs, if any.
- We confirm the access review cadence, the role model and the owners who approve and remove access rights.
How we build
- We deploy authentik in your environment with PostgreSQL, the server and worker containers, and the reverse proxy you already run.
- We configure providers, groups and roles so each application grants access based on documented rules and least privilege.
- We test failed logon handling, MFA enrollment and lockout behavior, and record the results against the agreed scope.
How we hand over
- You receive configuration documentation covering authentication settings, role design, provisioning steps and the owners of each control.
- We describe which authentik event logs exist, where they are stored and how to pull samples for internal audit or certification sampling.
- We walk your team through the access review procedure and the joiner, mover and leaver steps your ISMS procedures will reference.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and priced from that written scope.
- Ongoing support, upgrades and continuous testing are available as a retainer, so configuration stays aligned with your ISMS.
- Ask any implementation partner to confirm current authentik release support and upgrade notes with the vendor before planning changes.
