What ISO 27001 asks of workforce login and how SSO answers it
If you own the ISMS, you need to show that every system in scope uses secure authentication under Annex A control A.8.5, and that the allocation and handling of authentication information is controlled under A.5.17. An SSO platform such as Keycloak, authentik or ZITADEL can carry most of the technical enforcement: a single place to set login policy, MFA requirements, lockout and session rules, and a consistent record of who signed in and how. It cannot write your policy, run your access review or decide what counts as adequate. Those remain your organization's management process, and the certification body decides whether the evidence meets the standard. ISO does not certify organizations; accredited certification bodies do that work.
The 2022 edition of ISO/IEC 27001 contains 93 controls in four themes, taken from ISO/IEC 27002:2022: organizational controls (37), people controls (8), physical controls (14) and technological controls (34). A.8.5 sits in the technological theme and A.5.17 in the organizational theme, so an auditor will expect to see both a configured system and a documented process behind it. The NIST crosswalk relates A.8.5 to AC-7 (unsuccessful logon attempts), AC-8 (system use notification), AC-9 (previous logon notification) and IA-6 (authentication feedback), but NIST warns that mapped controls are not always equivalent, so treat it as a starting point and confirm the mapping with your auditor.
Start by building a control matrix that lists each in-scope application, its login path through the identity provider, and the settings that apply to it. Then confirm with your certification body which configuration exports and policy records they accept as evidence, and whether they want a sample of applications tested directly. Confirm too that your version of the identity platform still receives security fixes. The authentik security policy, for example, lists 2026.5.x and 2026.8.x as supported lines, and Keycloak's project plans regular minor releases, so the patch cadence must be part of your change process.
Mapping A.8.5 and A.5.17 to login policy, MFA, lockout and session settings
This table maps ISO/IEC 27001:2022 Annex A controls A.8.5 and A.5.17, along with the related NIST crosswalk controls, to the login, MFA, lockout, session and notice settings an SSO deployment needs. Read each row as a control requirement, what the function must do, and where Keycloak, authentik or ZITADEL typically carries the setting. Confirm exact setting names in each vendor's current documentation before writing them into your evidence pack.
| Requirement | What the function must do | How to configure in Keycloak, authentik or ZITADEL |
|---|---|---|
| A.8.5 Secure authentication | Make log-on depend on a secure procedure that matches the sensitivity of the information each application holds, under the access control policy. | Define per-application authentication flows or policies, so high-value applications require stronger steps than low-risk ones. Document the flow for each application in the evidence pack. |
| A.8.5 and NIST AC-7 (unsuccessful logon attempts) | Limit repeated failed log-ons and define what happens after the limit is reached, such as a temporary lock. | Enable brute-force or failed-login protection in the realm or instance security settings. Record the threshold, lock duration and unlock method, and confirm the values with your policy owner. |
| A.8.5 and NIST AC-8 (system use notification) | Show a notice before or at log-on that describes authorized use and monitoring, where your policy requires one. | Use a custom login theme or a banner in the login flow for the notice text. Keep the approved text and the theme version under change control so auditors can see the displayed wording. |
| A.8.5 and NIST AC-9 (previous logon notification) | Show users when their last successful or failed log-on occurred, so they can spot misuse of their account. | Check whether the chosen platform version and login flow provide this natively. If not, confirm with the vendor or your partner whether a custom step or an external notice is acceptable. |
| A.8.5 and NIST IA-6 (authentication feedback) | Avoid revealing secret or credential details during log-on, and keep error messages from helping an attacker. | Use generic failure messages in custom themes and flows. Test with invalid usernames and wrong passwords to confirm the responses are identical. |
| A.5.17 Authentication information | Control how passwords, passkeys, tokens and other credentials are issued, reset, stored and handled, with a management process and user guidance. | Set password policy (length, history, blocklists) in the realm or policy settings, and register passkeys or WebAuthn credentials through the enrollment flow. Keep a written standard and an export of the policy as evidence. |
| A.5.17 and A.8.5 (MFA by risk) | Require stronger authentication for higher-risk sign-ins, such as privileged roles, unfamiliar devices or sensitive applications. | Use conditional authentication or step-up flows where the platform supports them, otherwise apply MFA per application or role. Confirm which risk signals each platform version can evaluate. |
| A.8.5 session control | End idle and absolute sessions after a defined period, and protect session tokens from reuse. | Set idle and maximum session lifetimes per realm, client or flow. Record the values in the configuration export and confirm them against the policy owner's requirements. |
Which open-source identity platform fits which ISMS
Each platform below can support the authentication evidence behind Annex A controls 8.5 and 5.17, but they differ in license, protocol coverage, database and upgrade load, and which features sit behind a paid edition. The choice depends on your directory estate, your distribution model and how much of the identity stack your team can operate and document.
Keycloak for broad protocol coverage
Keycloak is Apache-2.0 licensed and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with LDAP and Active Directory user federation built in. It needs a supported production database and a synchronously replicated database for its high availability designs, which adds cost and operational work. Check the Operator approval mode you will use, since the Operator documentation recommends manual approval for updates, and plan a tested upgrade path for each minor release. Confirm the database and HA topology before you write the authentication policy.
authentik for a lighter PostgreSQL stack
authentik's core code is MIT licensed, but the authentik/enterprise directory is under a separate enterprise license. Since 2025.10 it runs without Redis, moving caching, tasks and sessions to PostgreSQL, so you should size PostgreSQL connections after upgrading. Security fixes cover the 2026.5.x and 2026.8.x series, so your patch cadence must match those supported lines. Enterprise features such as Entra ID integration, mTLS and enhanced audit logging need a paid subscription.
ZITADEL for passkeys and multi-tenancy
ZITADEL is AGPL-3.0 licensed and its README lists passkeys (FIDO2 and WebAuthn), OpenID Connect certification, SAML 2.0, SCIM and multi-tenancy. AGPL-3.0 applies network-use obligations to modified versions, so legal review matters if you change the code or offer it to outside parties. Use it where phishing-resistant login and SCIM provisioning are core to your control design. Confirm which features your version exposes in its documentation before you cite them as evidence.
FreeIPA for Kerberos-centric estates
FreeIPA suits organizations already running Linux hosts and Kerberos, with its own certificate authority and LDAP directory. It fits best where authentication is tied to domain logins rather than web SSO alone, and it may need a companion SAML or OIDC front end for SaaS and web applications. Confirm its current license, supported platforms and integration model with the FreeIPA project and your Linux distribution before you rely on it for evidence. Check how logon events reach your log platform, since that becomes part of your audit trail.
Licensing for distribution and enterprise features
Apache-2.0 and MIT allow broad internal use and redistribution with notice requirements, while AGPL-3.0 adds source obligations when a modified service is offered to users over a network. Where a platform has an enterprise directory or edition, the features auditors ask about, such as audit logging, password history and Entra ID connectors, may sit behind a paid license. Record which edition you run and which features it includes in your control evidence, so the configuration you export matches what you licensed.
Setting MFA by risk, lockout and session rules
For everyday workforce users on managed laptops, the goal is a login policy that is strict enough to satisfy your access control requirements without making routine work painful. Under ISO/IEC 27001 Annex A control A.8.5 (secure authentication), the policy should be documented, tied to the information the user can access, and enforced in the identity provider rather than left to each application. Keycloak, authentik and ZITADEL all let you express these rules as authentication flows or policies, so the same rule applies across connected applications.
- Password and credential baseline: Define the accepted first factor, such as a password or a passkey, and where passkeys are offered as the preferred option.
- MFA for all workforce logins: Require a second factor for every interactive staff login as the default, then document any exceptions with an owner and an expiry date.
- Lockout threshold: Set the failed-attempt count and lockout duration from your own risk assessment, then test that the lockout triggers as intended and that help desk unlock steps work.
- Session length and re-authentication: Set idle timeout and maximum session lifetime for standard roles, then confirm that sensitive applications can request a fresh login.
Before sign-off, check that the exported realm or policy configuration matches what the written standard says, and keep dated copies as evidence.
Administrators who manage the identity provider, production systems or security tooling carry the highest impact if an account is misused. Control A.8.5 expects authentication to match the sensitivity of the access, so privileged roles should not share the standard staff policy. Separate administrative accounts, step-up MFA for every administrative console, and stricter session limits are common design choices, and the exact settings are for your organization to decide.
- Separate privileged identities: Give administrators a dedicated account for administrative work, distinct from their daily account, so that policy can differ between the two.
- Phishing-resistant MFA: Prefer hardware-bound passkeys or FIDO2 security keys for administrative roles, where the platform supports them.
- Step-up triggers: Require fresh MFA before opening administrative consoles, changing MFA settings, creating clients or exporting user data.
- Lockout and alerting: Set lockout thresholds from your risk assessment, and forward failed and successful administrative logins to your monitoring so repeated failures are reviewed, not only blocked.
- Short sessions: Use shorter idle and maximum session times for administrative roles, and log each re-authentication.
Confirm that break-glass accounts are documented, protected by MFA that does not depend on the failing system, and tested on a schedule.
Logins from personal devices, unmanaged browsers or unfamiliar networks are where authentication is most often attacked. Conditional rules let you raise the requirement only when the context looks unusual, such as a new device, a new country or an unmanaged endpoint. Whether your identity provider can read device posture directly depends on the product and the integration you build, so confirm that capability for your chosen platform before you rely on it.
- Risk-based step-up: Trigger MFA when the device is unknown, the network is unfamiliar or the access is to sensitive applications, and document each trigger.
- Restricted access from unmanaged devices: Decide which applications can be reached from unmanaged devices at all, and limit session lifetime and re-authentication for those cases.
- Lockout for remote paths: Apply lockout rules to external login endpoints separately, with thresholds set from your own risk assessment and tested against password spray patterns.
- Shorter sessions and forced re-login: Shorten idle timeouts for unmanaged sessions and revoke sessions when a user reports a lost device.
- Logging of context: Record the device, network and MFA method used for each login so that auditors can see how the rule was applied.
Test these triggers with real user paths on each device type you support, and confirm that help desk procedures do not weaken them.
Evidence auditors ask for and which component produces it
This table maps each evidence item an assessor is likely to request for secure authentication to the component or document that produces it and what the organization should retain. Read it as a starting inventory for your own evidence folder, not as a checklist that guarantees an outcome. The certification body decides whether the evidence is sufficient for your scope, so confirm expectations with them before the audit.
| Evidence item | Producing component | What to retain |
|---|---|---|
| Access control and authentication policy | Management system document set (not produced by the identity platform) | Approved policy version, approval record, review dates and the link to the topic-specific access control policy |
| Authentication information management procedure | Management system procedure, with identity platform settings as the technical record | Procedure covering credential issuance, reset, handling advice given to staff, and the review history |
| Realm, client and flow configuration exports | Keycloak realm export, authentik blueprints or exports, ZITADEL instance configuration | Versioned exports stored in change control, with dates, hashes and the person who approved each change |
| Login policies, password and MFA rules | Keycloak authentication flows and required actions, authentik policies and stages, ZITADEL login policy | Exported policy settings for each realm or tenant, plus the dated record of each change and its reason |
| MFA enrollment records | Identity provider user credential data and enrollment events, reported through admin or audit tooling | Enrollment counts by population, exceptions with approvals, and the process for lost or replaced factors |
| Failed-login and lockout records | Identity provider event logs (brute force detection and failed login events) forwarded to a central log platform | Log export or retained index for the agreed period, with the lockout threshold settings that were in force |
| Administrator and configuration change audit logs | Admin event logs in the identity platform, plus the host and database audit trail | Who changed what and when, with ticket references, retained according to the log retention rule you define |
| Session timeout and token lifetime settings | Realm or tenant session and token settings, exported with the configuration | The values in force on each date, and records showing review or change approval |
| Upgrade and patch change records | Change tickets, release notes for the deployed version, test results in a staging environment | Version deployed, release notes reviewed, test evidence, rollback plan and sign-off for each upgrade |
| Access review outputs | Periodic review of accounts and privileged roles, often supported by identity governance tooling | Review scope, reviewer, decisions, removals completed and evidence that removals took effect |
What SSO tooling alone does not satisfy
An identity provider enforces authentication, but A.8.5 and A.5.17 also depend on processes, policies and accounts that sit outside SSO. The cards below cover the gaps auditors most often find when they test the SSO design against the control wording.
Authentication information management process
A.5.17 asks for allocation and management of authentication information under a management process, including guidance to staff on handling it. SSO centralizes login, but it does not write that process. Check that you have a documented lifecycle for passwords, passkeys, recovery codes and MFA tokens, with a named owner and records of who issued what. Confirm that staff guidance exists and that they have acknowledged it.
Documented access control policy
A.8.5 refers to secure authentication based on information access restrictions and the topic-specific policy on access control. Login rules in Keycloak, authentik or ZITADEL only implement that policy; they do not define it. Confirm the policy names which systems need which assurance level, who approves exceptions, and how the policy maps to realm, group and client configuration. Auditors will compare the two.
Service account and machine secret handling
Service accounts, API tokens, client secrets and CI credentials usually authenticate outside SSO and can bypass login policies entirely. Inventory every non-human credential, record its owner and rotation method, and decide where it is stored. A dedicated secrets platform such as OpenBao or Infisical may hold these, but confirm that the SSO design explicitly covers them.
Applications that cannot use SSO
Legacy applications, local administrator accounts, network devices and some database logins may not support SAML or OIDC. Each of these needs an alternative control, such as a gateway, a separate credential vault or documented compensating measures. Build a register that lists every application, its protocol, its login method and its compensating control, and review the register at each access review.
Directory and joiner-mover-leaver process
SSO grants access based on the accounts in the directory it reads, so its security depends on how accounts are created, changed and removed upstream. Confirm the authoritative source of identities, the approval steps for joiners and movers, and the time from a leaver event to disabling sessions across all federated applications. Keycloak's LDAP and Active Directory federation can reflect those states, but the HR or ticketing process must still trigger them.
Testing and operating controls over time
Auditors look for evidence that login controls worked during the audit period, not only that they were configured once. Keep exports of realm or tenant settings, change records for upgrades, test results for lockout and MFA enforcement, and logs of failed and successful authentication. Plan periodic reviews of these records. Ask your implementation partner how upgrades are tested and recorded, since Keycloak documents release cadence and the operator recommends manual approval mode.
Keeping the authentication controls running between audits
The authentication controls you evidenced for ISO/IEC 27001 are only as good as their operation after the audit. Keycloak ships four minor releases a year, and since Keycloak 26.0 the project says breaking changes in a minor release are opt-in. That protects a tuned configuration, but it does not remove the need to review each release notes entry against your login policies, MFA flows, lockout settings and session lifetimes. Assign an owner to read each release, test it in a non-production realm, and record the decision to adopt or defer. Each upgrade that touches a flow, a required action or a password policy should trigger a fresh export of the realm configuration, so the evidence you hand a certification body matches the system that is actually running.
If you run authentik, the security policy is the operating constraint to plan around. Versions 2026.5.x and 2026.8.x are the lines receiving security fixes, so a deployment on any other line is outside that support window and should be scheduled for upgrade. The project announces security releases at least 24 hours in advance, which is a short window for a team without a standing change process. Agree in advance who can approve an out-of-cycle patch, how it is tested against your MFA and session rules, and how the change is logged. For the Keycloak Operator, the documentation strongly recommends manual approval mode for operator updates, so an upgrade happens only when your change board approves it. Pair that setting with a runbook entry that re-exports configuration after every change.
ISO/IEC 17021-1 requires an accredited certification body to carry out at least one audit in each calendar year of a three-year certification cycle, either surveillance or recertification. The auditor will therefore expect to see current authentication evidence in most years, not only at the initial audit. Confirm with your certification body which evidence they sample during surveillance, and keep a dated export of realm or tenant settings, MFA enrollment reports and lockout configuration at each change. Note that the ISO/IEC 17021-1 cycle applies to the certification body's process, so your own review calendar should be set by your risk assessment and the body's requirements, not by the audit date alone.
Questions buyers ask about ISO 27001 SSO before hiring help
Does SSO alone make us ISO 27001 compliant?
No. ISO/IEC 27001 is a management system standard, and SSO only supports a few Annex A controls, mainly A.8.5 Secure authentication and A.5.17 Authentication information. Your organization still needs a risk assessment, a statement of applicability, documented policies, access reviews, logging and internal audits. Certification is issued by an accredited certification body, not by the platform vendor or by DeployOpen. What SSO gives an auditor is configuration evidence: login policies, MFA rules, lockout and session settings, and exported realm or tenant configuration that shows those rules are enforced. Ask your certification body early which evidence it expects for the controls you claim.
What drives the effort and cost of an SSO rollout?
The main drivers are the number of applications that must integrate, the protocols they support (SAML 2.0, OpenID Connect, LDAP or none), the directories to federate, and the MFA and passkey policy you need. Cost splits into infrastructure and database, integration work per application, MFA enrollment for staff, testing, documentation and ongoing support. Some costs are one-time, such as design and integration, while hosting, patching, upgrades and support recur. A quote should list the applications in scope, the environments (test, staging, production), the high availability design, the evidence package for auditors and what is excluded. Ask whether paid support, a paid edition or a per-user SaaS fee is included or assumed.
How long does an SSO rollout take, and what does it depend on?
Timing depends on the number of applications, how many can use standard protocols, the state of your directories, and how fast staff can enroll MFA. Legacy applications without SAML or OIDC support usually take the longest, because they need a proxy, a connector or a retirement decision. Upgrade testing and a high availability design also add time before production. This page does not state a duration, because the figure depends on your scope. In a written scope, ask for the phases, the applications in each phase, the acceptance criteria and the dependencies on your change windows and security approvals.
What must our internal team provide during an SSO engagement?
Your team typically provides the application owners and their technical contacts, access to source directories and existing identity data, decisions on MFA and session policy, approval for DNS, certificates and network paths, and a named owner for the identity provider after handover. Security and compliance staff should confirm which controls the audit scope claims and which evidence they will sample. Ask the implementation partner to list these inputs in the scope document with a named contact for each, so delays are visible early.
Can we run an SSO rollout ourselves?
Yes, if you have engineers who can operate PostgreSQL, Linux or Kubernetes, manage TLS certificates, and test protocol integrations. Keycloak, authentik and ZITADEL are all self-hostable under open-source licenses. The risks lie in the less visible work: high availability, patching, upgrade testing, backup and restore, and building the evidence pack. Keycloak documents that a high availability design needs a synchronously replicated database, and recommends manual approval for operator updates. A partner can take on any part of this under a fixed scope, or run the work alongside your team so knowledge stays in-house. Compare both options against the skills you have today.
Which license terms and paid editions matter for an SSO platform?
The license decides what you can run, modify and distribute, and it can change what you pay. Keycloak is licensed under Apache-2.0. authentik is MIT for most of its code, but the authentik/enterprise directory carries a separate enterprise license. ZITADEL is AGPL-3.0, which has obligations if you modify and offer the software over a network. Review the terms with your legal team, and confirm whether a vendor-supported distribution, such as Red Hat build of Keycloak, is needed for your support model. Ask every vendor which features sit behind a paid tier, because that changes the total cost of ownership.
Do we need authentik's enterprise features for Entra ID or audit logging?
Maybe, and you should confirm it on the current pricing and license pages before you decide. According to authentik's pricing page, the Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging are listed as enterprise-only features. If your ISO 27001 evidence depends on enhanced audit logging or password history, the open-source edition may not give you that evidence on its own. Map each control you claim to a feature, and check whether standard logs and configuration exports satisfy your auditor. The page lists enterprise prices, but DeployOpen does not publish its own pricing, so ask your vendor for current terms.
How DeployOpen scopes, delivers and supports this SSO work
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For ISO 27001 secure authentication, we start from the written control mapping for Annex A controls 8.5 and 5.17, then build the login, MFA, lockout and session configuration and the evidence that goes with it. We do not issue audit reports or certifications; the client's certification body makes that determination.
How we scope
- Agree in writing which identity platform (Keycloak, authentik or ZITADEL) and which applications are in scope for control A.8.5.
- Map current login policies, MFA coverage, lockout and session settings to the control wording and record the gaps.
- Confirm with your certification body which evidence they expect for A.5.17 and A.8.5 before build starts.
How we build
- Configure realms or organizations, password and passkey policy, and risk-based MFA steps as exported, version-controlled configuration.
- Set lockout, brute-force protection and session timeout values from the agreed policy, and test them against each application.
- Document the production database, high availability design and upgrade path, including the database requirements each platform publishes.
How we hand over
- Deliver a control mapping that links each configuration item to A.8.5 or A.5.17, with the export files that support it.
- Provide runbooks for account provisioning, credential handling guidance for staff, and MFA enrollment procedures.
- Hand over test records for login, lockout and session behavior so your team can repeat them after changes.
How we support
- Support is available as a retainer for upgrades, configuration reviews and security patch application on the chosen platform.
- Re-run login, MFA and session tests after each platform upgrade and before each surveillance or recertification audit.
- Confirm with the vendor which release line receives security fixes and agree a patch window in the retainer scope.
