What A.8.5 secure authentication asks for and why assessors care
When an auditor or a customer asks how logins are protected, the short answer is that A.8.5 requires you to choose authentication technologies and log-on procedures that match the access restrictions you have set, and to write that choice down under your access control policy. The control does not name a product or prescribe one method for everyone. A system holding payroll data and a marketing wiki do not need identical log-on rules, but each needs a reasoned rule that an assessor can trace from the information being protected, to the access restriction, to the way users prove who they are. The test is consistency between risk and login strength, not the presence of any particular feature.
The risks behind the control are familiar: stolen or reused passwords, credential stuffing from other breaches, password guessing against accounts with no lockout, and sessions or credentials exposed while they travel between the user, the application and the identity source. Each application can apply its own log-on logic, so one weak screen can undermine a strong policy elsewhere. In practice, the difficulty comes from scale and history. Organizations run SaaS applications, internal web apps, legacy systems that only accept local accounts, and several identity sources at once, such as a directory, a cloud identity provider and a few local admin accounts. Many of these cannot enforce the same second factor, lockout or session rule. Before planning changes, confirm with the control owner which systems hold sensitive information, which of them authenticate on their own, and where each rule is set.
Traceability matters because assessors compare your Statement of Applicability with what your systems actually do. The 2013 edition placed the same subject under A.9.4.2 Secure log-on procedures, and the correspondence table in ISO/IEC 27002:2022 Annex B links the two, which helps when your older documents still cite the previous numbering. Expect to show, for each system in scope, the chosen method, the reason it fits the access level, and how that setting is enforced. Related controls such as A.5.17 Authentication information and A.8.2 Privileged access rights overlap with this one, so define boundaries between them early. Confirm the exact wording of the control and its guidance in ISO/IEC 27002:2022 from the IEC Webstore before you write your own procedure.
Which systems, accounts and third parties fall under A.8.5
A.8.5 applies wherever a person, service or device proves who it is to reach information. The scope decisions below determine which logins need stronger authentication, and they should be aligned with the access restriction tiers in A.5.16, A.5.17 and A.8.2 so that the same access rules drive both the identity design and the evidence.
User-facing applications
Start with every application that holds customer, employee or company information and that a user signs into directly. For each one, record whether it authenticates users itself or delegates to a central service, and whether its log-on screen enforces lockout, feedback limits and session expiry. Applications that keep their own password stores are often the weakest link, so list them explicitly. Ask the owner which accounts exist outside the central directory.
Administrative consoles and privileged access
Administrative interfaces for cloud tenants, hypervisors, databases, firewalls and identity systems carry the highest access restriction tier. Treat them as a separate scope with the strongest authentication, separate admin accounts and a documented exception process. Under A.8.2, privileged rights are allocated and reviewed on their own, so confirm that the authentication method for each console matches the privilege level it grants.
VPN, remote access and internet-facing services
Anything reachable from outside the internal network needs stronger authentication than systems that only internal users can reach. Include VPN gateways, remote desktop brokers, webmail and public APIs with user logins. Check whether each entry point enforces a second factor for every user, or only for some groups, and whether legacy protocols still accept a password alone. Internal-only tiers may use a different but documented method.
SaaS logins and external identity providers
Business SaaS tools often sit outside the organization's infrastructure, yet they still hold regulated information. Inventory each tenant, record whether sign-in goes through a central identity provider, and check whether local accounts remain enabled for break-glass or vendor use. External identity providers used for federation are also in scope, because their authentication strength and account recovery flows determine the strength of every application that trusts them. Confirm which second factors each provider enforces.
Service and machine authentication
Service accounts, API clients, scheduled jobs and devices also authenticate, though no person types a password. Record which credentials they use, where those secrets are stored and who can read them. Human multi-factor controls do not apply to these identities in the same way, so the assessor will look for protected secret storage, rotation procedures and restriction of each account to the systems it needs. Document the approach for each class of machine identity.
Directory and identity source of truth
The directory that stores accounts and credentials is in scope itself, because a weakness there affects every system that depends on it. Confirm where the authoritative account list lives, which systems read from it, and how account creation, change and removal flow from HR records. Under A.5.16 and A.5.17, identity lifecycle and authentication information must be controlled, so the directory design and its change history form core evidence for this control.
How an assessor tests secure authentication
This table walks through the typical assessor test steps for A.8.5, the evidence requested at each step and the findings that recur. Read it as a preparation checklist: the assessor tests the design and operating evidence of your authentication controls, while your team or implementation partner configures and documents the systems.
| Test step | Evidence the assessor requests | Common finding |
|---|---|---|
| Read the access control and authentication policy | Topic-specific access control policy, authentication requirements by access level, approval and review records | Policy states MFA is required but does not say which systems or roles it covers |
| Sample systems in scope | Asset or application inventory, identity provider and application lists, sample selection rationale | Internet-facing or legacy applications outside the identity provider are missing from the sample base |
| Observe log-on flows | Screenshots or recordings of login flows, configuration exports showing required factors per application or group | Some applications accept password-only log-on while the policy requires a second factor |
| Observe MFA enrollment | Enrollment records, enrollment procedure, identity verification steps for new and replacement factors | Enrollment or factor reset can be completed by help desk with no identity check |
| Test lockout and failed-attempt handling | Lockout and throttling settings, failed-attempt logs, documented thresholds and reset procedure | Lockout thresholds exist in configuration but are not written down or approved |
| Check credentials are not exposed in transit | Evidence that log-on pages and APIs use encrypted channels, certificate and protocol settings, review records | Authentication endpoints still reachable over unencrypted or outdated protocols |
| Review shared and exempt accounts | List of shared accounts, MFA exemption register, justification, compensating controls, approvals | MFA exempt accounts or shared accounts with no owner or review date |
| Review exceptions | Exception register, risk acceptance, expiry dates, periodic review minutes | Exceptions granted and never reviewed or closed |
How to implement secure authentication step by step
This sequence turns A.8.5 from a policy statement into working login controls: each system's access needs are matched to a proportionate authentication method, the identity layer is chosen deliberately, and every step leaves records an assessor can check.
Inventory authentication paths and identity sources
List every way a person, service or device proves its identity to your systems: directory accounts, local application logins, API keys, shared administrative accounts, social or partner logins and any single sign-on already in place. For each path, record the identity source it relies on, the systems it protects and the owner responsible for it. Include legacy paths that still work even if they are rarely used, because assessors often find them during testing. The output is an authentication inventory that the organization owns and reviews, and the step is done when every system in scope maps to at least one documented path and owner.
Classify systems by access restriction
Using the inventory and the organization's access control policy, group systems by how sensitive the information is and how much access the policy allows, from public-facing services to administrative consoles holding production data. A.8.5 expects the strength of authentication to follow these access restrictions, so this classification decides where stronger methods are required. The output is a classification register that names each tier and the systems in it. The step is complete when the risk owner has signed off the tiers and no in-scope system is left unclassified.
Define the authentication policy and log-on rules
Write the topic-specific rules that each tier must meet: which factors are required, when re-authentication applies, how many failed attempts are allowed before a lockout, what a user sees after a failed or successful log-on, and how credentials must be handled in transit and at rest. Keep the rules short enough that engineers can implement them and reference them directly from the Statement of Applicability. The output is an approved authentication policy with version control and an owner. Confirm the exact thresholds with your risk owner and your own environment rather than copying values from another organization.
Choose the identity layer
Decide whether users sign in once through a central single sign-on service or identity broker that applications trust, or whether each application keeps its own login. Central options such as Keycloak or Zitadel can broker logins to existing identity providers, which keeps second-factor enforcement and lockout rules in one place, while per-application logins multiply the places those rules must be configured and tested. Document the choice, the systems that will and will not integrate, and the migration plan for applications that cannot integrate yet. The output is an architecture decision record. The step is done when the decision is approved and each application in scope has a named integration path.
Enroll second factors for each tier
Set up the factors your policy requires and enroll users against them. Options include time-based one-time passwords in an authenticator app, hardware security keys and FIDO2 passkeys, and tools such as authentik can validate several of these during login. Plan the recovery path as well, including static recovery codes and a documented identity-proofing procedure for lost devices, because weak recovery undermines strong primary factors. The output is an enrollment record for each user and factor type, kept in a system the organization can export. The step is done when enrollment coverage for the highest tier matches the policy.
Configure lockout and feedback behavior
Configure the identity layer so that repeated failed log-ons trigger the lockout behavior defined in policy, and so that the log-on screen gives only the feedback needed to proceed without revealing which part of the credential was wrong. Also configure notifications for previous log-on activity where the policy requires them and a system use notice where legal or contractual terms require one. Export the resulting settings as a configuration baseline stored under change control. The output is that baseline with a screenshot or config export per system. The step is done when test accounts confirm each rule fires as written.
Enforce encrypted transport for credentials
Confirm that every login path sends passwords, tokens and one-time codes only over encrypted connections, that legacy protocols which expose credentials are disabled, and that session tokens and certificates are protected at rest. Check that redirects, callbacks and identity brokering links enforce transport encryption end to end, and that any cryptographic settings follow the organization's A.8.24 cryptography rules. The output is a scan or configuration report showing protocols and cipher settings for each login endpoint. The step is done when no login endpoint in scope accepts unencrypted credentials.
Test, roll out and document
Test the full sequence with representative users: successful log-on with each factor, failed attempts up to and past the lockout threshold, recovery and re-enrollment, and failure paths when the identity provider is unavailable. Record the results, fix defects under change management, then roll out in stages with a rollback plan. Finally, update the inventory, classification register, policy, Statement of Applicability and operating procedures so that the documents match what runs in production. An independent auditor or certification body will judge whether the evidence is sufficient; the implementation partner or internal team prepares it. The output is a signed test report and a current document set, and the step is done when the evidence pack can be reproduced by someone who did not build it.
How central login flows protect credentials across applications
A central identity layer changes A.8.5 from a per-application problem into a single control point. Instead of each application deciding how users log on, how many failed attempts are allowed and which second factor is accepted, users authenticate once with a broker such as Keycloak or Zitadel, and applications trust the broker's signed assertions. The second factor check happens in one place, so enrolling, reviewing and removing factors, and enforcing lockout rules, can be governed once rather than repeated in every application. Credentials are also exposed to fewer systems, because applications receive tokens or assertions rather than passwords.
The broker also takes over the relationship with external identity providers. Keycloak can broker logins to existing OpenID Connect or SAML 2.0 identity providers, and Zitadel can sign users in through providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP. The organization should decide which providers are trusted, which claims or attributes are accepted from them, and whether the broker enforces its own second factor when an external provider has already performed one. Confirm in each product's documentation exactly which protocols, mapping options and multi-factor behavior apply to your version, rather than assuming parity between brokers.
Because the broker now makes the authentication decisions, its configuration becomes key evidence. An assessor will expect to see the realm or tenant settings, identity provider definitions, authentication flow and required-action configuration, token lifetimes, and the change history showing who altered them and when. Export these settings on a schedule, store them under change control, and test a sample login for each provider and factor type, recording the result. Clear evidence of this kind is what turns a central login design into demonstrable control of authentication information.
Evidence that passes A.8.5 and how to keep it current
An assessor testing A.8.5 Secure authentication looks for a written rule, proof that the live system enforces it, and records showing people followed it. The cards below cover six artifacts that connect those three things, along with how to refresh each one between audits so the evidence reflects the system as it is today.
Authentication and access control policy
This is the topic-specific rule that A.8.5 refers back to. It should state which systems require multi-factor authentication, which second factors are approved, how log-on attempts are limited, and who may approve exceptions. Check that the policy names the access restrictions it is tied to, because the control asks for authentication matched to those restrictions. Review it at least once a year and after any change to the identity provider. Record the version and approval date so an assessor can see it was current during the audit period.
Authentication configuration exports
Exports from the identity platform prove what is actually enforced. For authentik, the authenticator validation stage and the flows that call it show which second factors are checked during login. For Keycloak, export the realm settings that govern required actions, OTP policy and brute-force detection. Schedule these exports, store them with a timestamp, and diff them against the last export so unexpected changes are visible. Confirm lockout thresholds and lockout duration appear in the export, not only in the policy document.
Enrollment and exception registers
The register lists every user or service account enrolled in a second factor, the factor type, and the enrollment date. Separately, an exception register records each account allowed to sign in without the standard factor, with the business reason, the compensating control, the approver and an expiry date. Reconcile the enrollment list against the directory each quarter to catch orphaned tokens from leavers. An exception with no expiry or no named approver is the first thing an assessor will question.
Sampled log-on and failed-attempt logs
Assessors usually pick a sample of accounts and time windows and ask for the log-on and failed-attempt records behind them. Logs should show successful and failed sign-ins, the factor used, lockout events and the source address. Confirm the identity platform forwards these events to central logging, that the retention period matches your policy, and that someone reviews lockout spikes. Test the chain once a quarter by triggering a known failed log-on and locating it in the log store, so you can show the trail works before an auditor asks.
Transport configuration for credential exchange
Credentials and one-time codes must not cross the network in clear text. Keep the TLS configuration for login endpoints, the protocol versions allowed, and the certificate chain as exported artifacts. For federated sign-in over OpenID Connect or SAML 2.0, keep the metadata and redirect URI settings that show where tokens and assertions are sent. Scan the login endpoints after each certificate renewal or proxy change, and file the scan output with the date so the transport evidence matches the configuration in force.
Periodic review records
Reviews show the controls are maintained, not just installed. Record each review of the policy, the enrollment register, the exception register and the configuration exports, with the reviewer, the date, the findings and the follow-up owner. A quarterly exception review with signed minutes is usually enough to show the cycle is working. Use the same review template every time so a sequence of records is easy to compare. Ask your certification body to confirm how many review cycles it expects in your audit period.
What meeting A.8.5 costs in money and effort
This table breaks down the cost components of meeting A.8.5 Secure authentication, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request, since no figures are published here and every amount depends on your own environment. The main takeaway is that open-source identity platforms remove license spend, but hosting, integration and evidence upkeep still carry real cost.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it, and what to ask for in a quote |
|---|---|---|---|
| Identity platform licenses or hosting | Software vendor for commercial licenses; cloud provider or data center team for hosting | Licenses usually recur; self-hosted open source has no license fee but still has hosting | Identity source count and user volume. For self-hosted options, ask the partner to price the compute, storage, backup and high availability you actually need. |
| Engineering for integration and configuration | Internal platform or security engineers, or an implementation partner under a fixed-scope agreement | One-time for initial build, recurring for changes | Number of applications, legacy systems and protocols in use. Ask for a written scope listing each application, its protocol and the second-factor policy. |
| Second-factor hardware or app rollout | Organization buys hardware tokens or relies on users' own authenticator apps; partner may script enrollment | One-time per device; recurring for replacements and new joiners | User count, device mix and whether hardware keys are required for privileged users. Ask what enrollment methods the design supports. |
| User support during enrollment | Internal help desk or service desk staff | One-time during rollout, recurring for lost-device and reset requests | Number of users, time zones and self-service options. Ask how account recovery and lockout resets are handled and who verifies identity. |
| Evidence upkeep | Internal compliance or security staff; partner if retained | Recurring | How often configuration, enrollment and lockout settings are exported and retained for assessors. Ask for an evidence schedule and where artifacts are stored. |
| External penetration or configuration review | Independent testing firm or DeployOpen-style security testing provider | Usually one-time per release, recurring if scheduled | Number of exposed login endpoints, custom authentication flows and API authentication. Ask for the test scope, method and retest terms. |
| Auditor sampling and assessment | Accredited certification body or independent auditor | Recurring with each audit cycle | Number of sites, in-scope systems and sampled log-on events. Ask the certification body to confirm its audit plan and fee basis before engagement. |
| Lockout and credential protection tuning | Internal engineers; partner if fixed-scope | One-time, with periodic review | Threat profile and user population. Ask for documented lockout thresholds, notification behavior and how credentials are protected in transit. |
Who owns A.8.5 and what is worth outsourcing
Your organization owns A.8.5 in full. Under ISO/IEC 27001, the control is yours to design, approve and operate, and no partner or auditor can accept the authentication risk on your behalf. The people who answer for the control are the ones who decide which systems require multi-factor authentication, how long sessions last, what happens after repeated failed log-ons, and when an exception is granted.
- Policy and access decisions: Set the topic-specific access control policy that the control refers to, and decide which user groups, administrators and service accounts need which authentication strength.
- Exceptions: Approve, time-limit and review every exception to MFA or lockout settings, with a named owner and a recorded reason.
- Risk acceptance: Document residual authentication risk, such as legacy applications that cannot enforce a second factor, and have the accountable manager sign it.
- Operation and review: Review failed log-on trends, enrollment gaps and dormant accounts on a schedule you define.
- Vendor selection: Choose the identity platform and confirm its capabilities against your own requirements rather than relying on a partner's assumptions.
Before an assessment, check that every decision above has a dated owner, a written rationale and a record that someone reviewed it.
An implementation partner can prepare the systems that enforce A.8.5 and the evidence that shows they work. The partner does the technical build inside your infrastructure, but does not decide policy, accept risk or certify the result. Scope, deliverables and timelines are normally agreed in writing before work starts, so the boundaries are clear from day one.
- Broker configuration: Configure the identity broker and single sign-on so applications rely on one login flow, for example through a platform such as Keycloak or authentik.
- MFA rollout: Enroll second factors, set up recovery paths and migrate users in phases, with a fallback plan for lockouts.
- Evidence exports: Produce configuration exports, enrollment reports, authentication logs and change records that your team can retain and present.
- Test support: Run functional tests of lockout, MFA prompts and credential handling, and document the results for your own review.
- Knowledge transfer: Hand over runbooks so your staff can operate the platform after the engagement ends.
Ask the partner to state in writing which evidence it produces, which decisions it only supports, and whether it will also operate the platform under a separate retainer.
Only an independent auditor or certification body can test A.8.5 and issue a certificate or report. The auditor examines whether the control is designed appropriately and whether it operates as described over the period in question. Its independence depends on not having designed or implemented the controls it is testing, so the auditor must keep its role separate from the implementation work.
- Design testing: Check that the policy, Statement of Applicability entry and technical settings match the risk the organization has documented.
- Operating testing: Sample log-on records, MFA enrollments, lockout events and exception approvals to confirm the control worked as described.
- Reporting: Issue the audit findings, nonconformities or certificate under the accredited scheme, and never sign off on work the auditor helped build.
- Conflict checks: Confirm that the audit firm has not provided the implementation or evidence preparation that it is now assessing.
- Accreditation: Verify that the certification body is accredited for ISO/IEC 27001 before relying on its outcome.
Before engaging an auditor, ask how it will handle a request to review systems that a consultant configured for you.
Where authentication controls usually fall short in audits
Assessors rarely fail A.8.5 because a organization has no MFA product. They fail it because the stated rule and the actual behavior differ on some path, account or channel. The six gaps below are the ones that most often turn a sound policy into an audit finding, and each one has a closing action the organization can check before the assessor arrives.
MFA missing on admin and legacy paths
Multi-factor authentication is often enforced on the main web login but not on administrative consoles, VPN fallbacks, legacy protocols or older applications that still accept a password alone. An assessor will test the paths that matter most for the access restriction in your policy, so check every route into privileged and sensitive systems. Close it by listing each login path and recording whether a second factor is enforced on it.
Exceptions without approval or expiry
Teams frequently obtain a temporary exemption from MFA or a password rule for a vendor, a batch job or a deadline, and the exemption then stays for years. Without a named approver, a business reason and an end date, the exception becomes an unmanaged gap that contradicts the access control policy. Close it by keeping a register of every exception with an owner, approval record and expiry date, and reviewing the register on a fixed schedule.
Lockout thresholds undocumented or untested
Many organizations configure account lockout or throttling after failed log-ins but cannot show the setting in writing or prove that it works. An assessor will ask for the documented threshold, the lockout duration and evidence that a test attempt triggered it, and will also check that the setting matches what the policy says. Close it by documenting the thresholds in the policy and running a dated test that shows the lockout and the resulting log entry.
Shared and service accounts without rules
Shared administrator logins, generic team accounts and service accounts often sit outside the identity provider, have no second factor and use passwords that never rotate. Each one weakens the link between a log-on and a named person, which undermines both authentication and accountability. Close it by inventorying every shared and service account, assigning an accountable owner, and stating how each one authenticates (for example, with a certificate or a vaulted secret instead of a shared password).
Credentials sent over unencrypted channels
Log-on forms, API calls, directory binds and legacy services sometimes transmit passwords or one-time codes in clear text, or accept connections without verifying the server. Assessors look for encrypted transport on every authentication flow, including internal traffic and recovery channels such as email or SMS codes. Close it by capturing network traces or configuration for each authentication endpoint and confirming that it requires encrypted transport with certificate checks.
No evidence of periodic review
Authentication settings often pass the first audit and then drift as applications, users and vendors change, with no record that anyone reviewed them afterward. An assessor will expect dated review records that compare configured settings with the policy and show that exceptions and accounts were re-examined. Close it by scheduling a recurring review of MFA enrolment, exceptions, lockout settings and shared accounts, and keeping the signed output as evidence.
Questions buyers ask about A.8.5 before hiring help
How much effort does A.8.5 usually take compared with the rest of Annex A?
A.8.5 is usually a narrow control in effort terms, because it concentrates on how people and services log in. Most of the work sits in a few places: the identity provider, multi-factor settings for administrative and remote access, lockout and login-failure behavior, and the procedures that govern them. Controls that span many systems, such as logging, configuration management or supplier oversight, often take more time because they touch more of the estate. Effort still depends heavily on how many applications already rely on separate logins. Ask a potential partner to list the systems in scope, how many of them use local accounts, and which ones cannot yet use central authentication. Those three facts drive most of the estimate.
Can a self-hosted open-source identity layer satisfy A.8.5?
An open-source identity layer can provide the technical mechanisms A.8.5 asks for, but it does not satisfy the control by itself. The organization must decide which access needs multi-factor authentication, how log-on procedures and lockout behave, and how credentials are protected in transit, then document those decisions in its policy. Tools such as authentik, which validates TOTP apps, WebAuthn and FIDO2 passkeys during login, Keycloak for single sign-on over OpenID Connect and SAML 2.0, and Zitadel for brokering external identity providers can each cover parts of this design. Confirm with the vendor and your own tests which second factors, lockout settings and protocols your chosen version supports before you write them into the Statement of Applicability.
What does the internal team need to provide for A.8.5?
The internal team owns the decisions and the evidence, even when an implementation partner builds the systems. Expect to provide a named owner for the identity platform, a list of systems and user groups with their access restrictions, and a decision on which accounts are exempt from multi-factor authentication and why. The team also needs to approve the topic-specific access control policy the control relies on, and to run the recurring reviews that show the settings still work: enrollment checks, failed log-on reviews and periodic testing of recovery paths. Without these owners, the technical rollout tends to stall after go-live. Ask the partner to name the internal roles it expects before work starts.
How long does A.8.5 implementation take?
Timing depends on scope, and no fixed duration applies to every environment. The main drivers are the number of applications to move to central login, whether legacy systems can accept modern protocols, how many users must re-enroll second factors, and how quickly the internal team can approve policy and access decisions. A fixed-scope engagement starts with a written list of systems, deliverables and milestones, and that document is the right place to set dates. Ask for the schedule to show which items depend on the client, such as access reviews or change approvals, so delays are visible early.
Can the implementation partner also be the auditor for A.8.5?
No. An implementation partner prepares the systems, configurations and evidence, but only an independent auditor or certification body can assess conformity and issue a certificate. Under ISO/IEC 17021-1, certification bodies must be independent of the organizations they audit, and a firm that designed the controls cannot also test them as the independent assessor. Using the same firm for both roles would weaken the assurance a customer or regulator relies on. Ask the partner to confirm in writing that it will not perform the certification audit, and select the certification body separately.
What should a quote for A.8.5 work include?
A useful quote follows from a written scope, so it should name the systems, user populations and identity protocols in scope, and the deliverables for each. Ask it to separate one-time work, such as design, deployment, migration of accounts and documentation, from recurring work, such as upgrades, monitoring, access reviews and retained support. Check whether it covers testing of multi-factor authentication, lockout and recovery paths, and whether the evidence pack is included. Confirm what the client must provide, the assumptions behind the schedule, and how changes to scope are priced. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so the written scope is the basis for any figure.
Open-source identity tools that can produce A.8.5 evidence
Four self-hosted open-source identity platforms can produce much of the evidence an assessor will ask for under A.8.5, but each covers a different part of the problem. authentik (MIT) is the closest fit for multi-factor enforcement at the login point: its authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Its configuration, flow bindings and the list of enrolled factors per user can be exported as evidence that second factors are required where the policy says they are. Confirm which factor types you will permit, since SMS and email codes are weaker than passkeys and your access restriction policy may exclude them for privileged accounts.
FreeIPA (GPL-3.0-or-later) suits organizations that keep Linux hosts, LDAP-based directories and Kerberos in one place. It supports HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys, and it can proxy OTP checks to an existing RADIUS server during migration, which lets a legacy VPN or network appliance keep working while you move to MFA. Keycloak (Apache-2.0) and Zitadel (AGPL-3.0-only) address the application side. Keycloak provides single sign-on, so users authenticate once with Keycloak rather than separately in each application, and it supports OpenID Connect, OAuth 2.0 and SAML 2.0 and can broker logins to existing identity providers. Zitadel acts as a central identity broker, letting users sign in through external providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP. Brokering moves the authentication decision to one place, which simplifies evidence, but it also means the broker's own MFA and lockout settings become critical.
No product here automatically satisfies A.8.5. Before you cite any of them in a Statement of Applicability, confirm in your chosen version how account lockout after failed attempts, login failure messages, session timeouts and the logging of authentication events are configured and where those logs are sent. Test each setting against a sample account, keep the configuration under version control, and ask your certification body which evidence it expects for the factors you have decided to rely on. Implementation partners can build and document these configurations, but the organization owns the policy choices and an independent auditor decides whether the evidence is sufficient.
How DeployOpen scopes and prepares A.8.5 evidence
The sequence below turns A.8.5 secure authentication into a written scope, a hardened self-hosted identity layer in the client's own infrastructure, and an evidence pack the organization and its independent auditor can test. DeployOpen prepares the systems and evidence; the organization owns its controls and only an independent auditor or certification body issues reports or certificates.
Agree the authentication scope in writing
Before any work starts, DeployOpen and the client list every system that people, services and devices use to log on, including the access restrictions each one falls under and the topic-specific access control policy that governs them. The client confirms which applications sit behind single sign-on, which need direct credentials, and which privileged paths are in play. The output is a signed fixed-scope document naming the authentication paths, deliverables and timeline. Ask the client to confirm that the scope matches their Statement of Applicability entry for A.8.5.
Map requirements to the control and its neighbors
DeployOpen traces each agreed authentication path to the control wording and to closely related Annex A controls: A.5.16 identity management, A.5.17 authentication information and A.8.2 privileged access rights. The team checks crosswalk entries, including NIST's and ENISA's mappings, only as starting points, because those sources caution that mapped controls are not always equivalent. The output is a requirement register that the client's own risk owners review and accept. Any gap between the client's policy and the register is logged as a decision for the client to make.
Deploy the self-hosted identity layer
DeployOpen installs the chosen open-source identity components inside the client's cloud accounts, data centers or air-gapped network. Depending on the scope, this may include a central identity broker or single sign-on service such as Keycloak or Zitadel, and a second-factor service such as authentik or FreeIPA with HOTP and TOTP tokens. Each component is configured to the agreed policy for multi-factor enrollment, log-on attempt limits, lockout behavior and secure transport of credentials. The output is a running environment that the client can inspect, with installation records kept in the client's infrastructure as code repository.
Harden and test the log-on procedures
DeployOpen configures unsuccessful log-on limits, lockout and retry handling, session timeouts, system use notices and the way log-on feedback is shown to users, so that error messages do not reveal which part of the credential was wrong. The team then runs documented test cases for each path: valid enrollment, failed second factor, lockout and recovery, and credential transmission over encrypted connections only. The output is a test script, its results and the remediation tickets for any failure. Ask the client to confirm which test results they will treat as acceptance.
Document configuration and enrollment procedures
DeployOpen writes the configuration baseline, enrollment and recovery procedures, and the administrator runbook, then reviews them with the client's operators so they can run the system without the implementation team. The documents record which factors each user group may enroll, how recovery codes are issued and stored, and who approves exceptions. The output is a versioned document set with named owners and review dates set by the client. The client remains responsible for approving the procedures and for enforcing them after handover.
Assemble the evidence pack
DeployOpen collects the artifacts an auditor will ask to see: the agreed scope, the requirement register, configuration exports, access logs showing successful and failed log-ons, enrollment records, test results and the approved procedures. Each item is labeled with the control it supports and the date it was produced. The team checks that logs cover the authentication events that were tested, and flags gaps. The output is an evidence index that the client can hand to its internal assessors and to the independent auditor, who decides whether the evidence is sufficient.
Hand over to the client and their auditor
DeployOpen runs a handover session where the client's security and operations staff take ownership of the identity layer, the runbooks and the evidence index. The client decides how to share evidence with the independent auditor or certification body, which alone issues any report or certificate. Any remaining work, such as upgrades or continuous testing, moves to a separate written agreement, such as a retainer. The output is a signed handover record listing open items and who owns each one.
