164.312(d) Person or entity authentication requirements

What 164.312(d) person or entity authentication asks for

If you are preparing for an audit, building a system that holds ePHI, or buying a platform that will, the question is whether you can show that anyone or anything reaching that ePHI has been checked to be who it claims to be. Section 164.312(d) requires procedures to verify exactly that for any person or entity seeking access to electronic protected health information. The standard has no implementation specifications. Appendix A to Subpart C marks it as required, so you cannot treat it as optional, but the text leaves the method to you. The regulation defines authentication (164.304) as corroborating that a person is the one claimed. That corroboration is the control: a username alone is an identifier, while a password, token, certificate or biometric check that confirms the identity behind it is authentication. The risk the standard targets is impersonation and credential reuse, where a stolen or shared password lets an attacker or an insider appear as a legitimate clinician, billing user or service.

The current text does not name multi-factor authentication. It asks for verification procedures and leaves you to decide, through your risk analysis, which options fit each system. The NIST resource guide NIST SP 800-66 Rev. 2 describes this work as determining which systems need authentication, evaluating the options available, and selecting and implementing them. The January 6, 2025 proposed rule (90 FR 898) would change this. It would rename the standard as authentication and require multi-factor authentication on all technology assets in relevant electronic information systems, with limited exceptions. That is a proposal, not a final rule. As of October 2026, no final rule has been published, so the existing text governs what an assessor will test today. Confirm the current status in the Federal Register and the Unified Agenda before you set a deadline based on it.

Most of the difficulty comes from scope rather than from the concept. Organizations run many systems that touch ePHI, including EHRs, imaging viewers, billing tools, file shares and reporting databases, and each needs its own authentication decision. Service accounts and integration credentials often have no interactive user at all, so they are easy to leave outside the review. Legacy applications may only support local accounts or cannot redirect sign-in to a central identity provider, which pushes teams toward shared logins that the unique user identification specification rules out. Start by inventorying every system and account path into ePHI, mark which ones cannot use central sign-in, and document the compensating method and the reasoning for each. That inventory is the evidence an assessor will ask for first.

Which systems need 164.312(d) person or entity authentication

Authentication scope is set by where ePHI lives and who or what can reach it, not by a list of applications. Each decision below changes how many sign-in paths must be verified, documented and tested. NIST SP 800-66 Rev. 2 (section 5.3.4) starts by asking where authentication applies to current systems and applications, so the entity's own risk analysis should drive the boundary.

Systems that hold or reach ePHI

Start with the risk analysis inventory of electronic information systems that store, process or transmit ePHI, then add every system that can reach them, including directories, VPN gateways, remote desktop brokers and reporting tools. A system that only passes ePHI through is still in scope if it can authenticate someone into a system that holds it. Effort grows with each sign-in path that must be inventoried, tested and documented, so the inventory is usually the largest early task.

Workforce and privileged administrators

Employees, clinicians, billing staff and system administrators all need verified identities before reaching ePHI. Administrators with rights to change access, export data or disable logging usually deserve the strictest verification and the closest review, because a compromised administrator account affects every system they manage. Ask which accounts are shared, which are local to a single application and which come from a central identity source.

Contractors and third-party staff

Consultants, locum clinicians, outsourced billing teams and vendor support engineers often sign in with accounts the entity did not create. Each external identity needs a documented verification method, a defined end date and a removal step when the engagement ends. Confirm whether the vendor uses its own identity provider and whether the entity can see and revoke those sessions.

Patients using portals and apps

Where patients reach ePHI through a portal, mobile app or telehealth service, the entity must decide how strongly to verify each person and how to handle account recovery. Self-service registration, password resets and identity proofing are common weak points. Confirm which of these steps the entity runs itself and which a portal vendor performs, and document the answer.

Service accounts, APIs and backup jobs

Non-human actors such as scheduled backup jobs, interface engines, API clients and integration scripts also authenticate to ePHI systems. They often use long-lived passwords or static keys stored in configuration files, which the entity must inventory, rotate and restrict. Check which jobs can read or export ePHI, who owns each credential and how a leaked key would be detected and revoked.

Cloud, hosting and integration partners

Where a hosting provider, business associate or data exchange partner signs in to the entity's systems, the trust relationship is part of the authentication scope. Federated sign-in, cross-tenant access and shared administrative consoles need explicit records of who verifies the partner and how access is withdrawn. Confirm these arrangements against the business associate agreements and the entity's own access procedures.

How an assessor tests 164.312(d) person or entity authentication

This table walks through the steps an assessor typically takes to test whether an entity verifies identity before granting ePHI access. Read each row as a test step, what the assessor looks at, the documents and records they ask for, and the gaps that most often come up. The main takeaway is that assessors test the actual login paths and the documented decisions behind them, not just whether a policy exists.

Test step	What the assessor examines	Evidence requested	Common findings
Inventory of ePHI systems and login paths	Whether every system that stores, processes or transmits ePHI is listed, along with each way a user, administrator or integration reaches it	System inventory, network and application diagrams, list of login paths including VPN, remote access, portals and APIs	Systems missing from the inventory, or admin consoles and legacy interfaces that bypass the main sign-in
Sample of systems verifying identity before access	Whether a sample of systems requires the entity to confirm the user is who they claim before granting access to ePHI	Configuration exports, screenshots or test logins showing the sign-in step, identity provider settings, sample user onboarding records	Applications that accept a username alone, or that rely on a network location as proof of identity
Service and non-human account authentication	How application-to-application, batch, scheduled and API accounts prove their identity, and who controls their credentials	Service account register, credential storage and rotation records, API client configuration, key or certificate issuance logs	Shared or hard-coded credentials, service accounts with no owner, and secrets stored in plain text in scripts
Documented authentication decisions	Whether the entity recorded which authentication options it evaluated and why it selected each one for each system	Authentication standard or procedure, decision records, approval history, mapping of each system to its chosen method	Policies that describe a method no system uses, or decisions that were never revisited after a system changed
Link to the risk analysis	Whether the authentication choices trace back to identified threats and risks to ePHI in the entity's risk analysis	Current risk analysis, risk management plan entries for authentication, remediation tracking for identified gaps	Risk analysis silent on authentication, or open risks about weak sign-in that have no owner or date
Testing of rejected and failed logins	Whether failed, locked or rejected sign-in attempts are refused and recorded, and whether access is denied to unauthenticated users	Authentication logs for failed attempts, account lockout settings, test results from a controlled failed login	Failed attempts not logged, lockout disabled, or error messages that reveal whether a username exists
Account lifecycle and credential recovery	How identities are created, changed and removed, and how password resets or recovery codes verify the requester	Joiner, mover and leaver records, password reset procedure, recovery workflow configuration	Reset flows that send credentials to unverified channels, or accounts that stay active after staff leave
Multi-factor authentication status	Whether the entity has used a second factor where it chose one, and how that choice was documented	Factor enrollment reports, policy settings showing which users or systems require a second factor, documented exceptions	Second factors enabled for some users but not all, with exceptions that were never approved or documented

How to implement 164.312(d) person or entity authentication in order

This sequence takes an organization from knowing which systems and login paths touch ePHI to a documented, tested and periodically reviewed set of authentication decisions. Each step produces an artifact that an assessor can trace back to the risk analysis.

Determine authentication applicability to systems
Start by listing every system, application and service that creates, receives, stores or transmits ePHI, then state for each one whether it requires the entity or person to prove who it is before access. The security official or system owner leads this with IT input, and the work is done when every in-scope system has a recorded applicability decision. Keep the list tied to the systems named in the risk analysis so that nothing holding ePHI is missing.
Inventory every login path
For each in-scope system, record every way a user, administrator, service account, API client or automated job can sign in or obtain access. Include SSO connections, local accounts, break-glass accounts, vendor support access and machine-to-machine credentials. The output is a login path inventory, and it is complete when an administrator can reproduce each path from the list without finding a new one.
Evaluate authentication options
Compare the options available for each login path, such as password policy, multi-factor methods (authenticator apps, security keys, passkeys), federation through an identity provider, client certificates and workload identity for services. NIST SP 800-66 Rev. 2 describes evaluating available options as a key activity for this standard. The output is a short evaluation note per path that records the options considered, their limits and the reasons for ruling options in or out.
Select and implement options per system
Choose one authentication approach for each login path and configure the system to enforce it, typically through a central identity provider where the application supports delegated sign-in. Confirm the configuration with the system owner and the people who will use it, and note any path that cannot yet meet the chosen approach. The output is a configuration baseline per system, and the step closes when each path either enforces the chosen method or has a documented exception with an owner.
Document decisions and tie them to the risk analysis
Write a decision record for each system that states the applicability finding, the login paths, the options evaluated, the option selected and the reason it fits the risk identified for that system. Link each decision to the risk analysis entry it addresses, and have the security official approve the record. The record is complete when an assessor reading one system can follow the chain from risk to decision to configuration without asking for context.
Test successful and failed logins
Test each login path with valid credentials, and also with invalid passwords, missing second factors, expired certificates, revoked tokens and disabled accounts. Confirm that each attempt succeeds or fails as the decision record says, and that failed attempts appear in the audit logs. The output is a dated test result for each path, and the step closes when every test matches the expected outcome or a defect is logged and fixed.
Review authentication periodically as systems change
Set a review trigger for new systems, major upgrades, identity provider changes, new vendors with access, staff role changes and new service accounts, and repeat the inventory, evaluation and testing for affected paths. Keep the decision records and configuration baselines under version control or change management so that each change has a reason on file. The step is working when the inventory and decision records still match the live environment at the time of the next assessment, and the review interval itself should be set by the entity's own policy.

Which evidence shows 164.312(d) authentication works

Authentication under 164.312(d) is tested as a process, not a single setting. The cards below cover the decision trail an assessor reads first, the configuration and enrollment records that show the decisions were implemented, and the logs and reviews that show the controls keep working between audits. Keep each artifact dated and current so it can be produced without reconstruction.

Authentication applicability inventory

This is a register of every system, application and interface that touches ePHI, with a note on how each one authenticates people and software. An assessor uses it to confirm that no system was skipped, including older applications, service accounts, APIs and vendor-hosted tools. Check that the inventory lists non-human identities such as batch jobs and integrations, and that each entry names an owner. Reconcile it against the asset inventory from your risk analysis each time either one changes.

Option evaluation and decision record

This record shows the authentication options you considered for each system, why you chose one, and who approved it. NIST SP 800-66 Rev. 2 describes evaluating available options and selecting and implementing them, so the assessor expects to see that sequence. Record the criteria used, such as supported protocols, second-factor methods and recovery paths, and any risk accepted where a preferred option was not feasible. Store decisions in version control or a change system so the history is visible.

Identity provider configuration exports

Configuration exports from your identity provider show the settings that actually enforce authentication, such as password rules, session lifetimes, enabled second factors and which applications are bound to which providers. Assessors compare these exports against the decision record to confirm the two agree. Export on a schedule and keep the files under change control, so each change is traceable to a ticket. Where a platform stores these settings in files, such as realm or policy definitions, keep those files in version control.

MFA enrollment reports

Where your organization uses multi-factor authentication, enrollment reports show which accounts have registered a second factor and which have not. The current standard does not mandate MFA, but the 2025 proposal would require it on relevant systems, so these reports are also a useful early measure of readiness. Ask whether the platform can enforce registration for all users or only for local accounts, and document any exceptions with their approvals. Run the report at a fixed interval and retain each copy.

Successful and failed authentication log samples

Log samples show authentication working in practice: successful sign-ins tied to unique identities, denied attempts, lockouts and administrative logins. Assessors usually ask for a sample chosen by them, so keep logs centralized and searchable across the period under review. Confirm that logs capture the user or service identity, the time, the source and the outcome, and that they are protected from alteration. Pair these samples with the audit controls evidence required by 164.312(b).

Periodic authentication review record

This is a dated record of the review in which someone confirmed that the inventory, decisions and configurations still match how systems behave. It should note changes since the last review, findings such as stale service accounts or unenrolled users, and the corrective actions with owners and closure dates. Assessors look for evidence that the review happened on a set cadence and that its findings led to action. Schedule the review, assign a named reviewer and keep the signed output with the other artifacts.

What meeting 164.312(d) person or entity authentication costs

This table compares the main cost components of meeting the authentication standard, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a written scope and to ask vendors and assessors for line-item quotes. No figures are given because none are supplied for this standard, so the costs are shaped by your environment, not by a fixed price.

Cost component	One-time or recurring	What drives it	How to keep it down
Identity platform licenses or hosting	Recurring	Number of identities, whether you buy a commercial product or run open-source software in your own infrastructure, and the hosting footprint	Self-hosted open-source platforms such as authentik, FreeIPA, Keycloak or Zitadel remove license fees but add operations staff time; confirm each product's license terms with its vendor
Engineering time to integrate applications	One-time, with ongoing changes	Count and age of applications holding ePHI, mix of OAuth2, OpenID Connect, SAML, LDAP or proxy integrations, and legacy apps without modern sign-in	Inventory applications first, prioritize those with ePHI, and standardize on one protocol where the application supports it
MFA hardware or authenticator costs	One-time per user or device, plus replacement	Choice of TOTP apps, U2F security keys, passkeys or one-time passwords by email or SMS, and the number of users who need hardware tokens	Allow authenticator apps and passkeys where risk analysis supports them; ask vendors to confirm which second factors their platform supports
Configuration of MFA enforcement policy	One-time, with periodic review	Whether second factors apply to every user or only to locally authenticated users, and how exceptions and break-glass accounts are handled	Document the policy decision in the risk analysis and set enforcement in the platform's login policy rather than through manual steps
Evidence upkeep	Recurring	Frequency of access reviews, retention of authentication logs, change records for policy updates, and documentation of the chosen authentication options	Generate evidence from the identity platform's logs and configuration exports on a fixed schedule, not on demand before an audit
External penetration testing or configuration review	Recurring or per engagement	Scope of systems tested, whether authentication flows and password reset paths are included, and the depth of the test	Limit scope to authentication paths and ePHI-facing applications, and agree the scope and deliverables in writing before testing starts
Assessor sampling and review time	Per assessment	Number of applications and user populations the assessor samples, and the quality of your evidence index	Keep one evidence index that maps each application to its authentication method, owner and last review date
Ongoing staff time for operations	Recurring	Patching, upgrades, certificate rotation, backups and on-call coverage for the identity platform	Choose a platform your team already operates, automate upgrades and backups, and consider a support retainer for the platform

Which open-source identity tools support 164.312(d) evidence

Each tool below can act as the place where people and services prove who they are before reaching ePHI. None of them makes a system compliant on its own: the covered entity still decides where authentication applies, which factors it requires, and how it proves that sign-in was enforced. Confirm each capability against current documentation before you rely on it in a risk analysis.

authentik as the sign-in layer

authentik (MIT) works as an identity provider. Applications delegate sign-in to it through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so one login policy can cover many ePHI applications. The evidence to collect is the provider configuration for each application, showing that no ePHI system accepts a local password path that bypasses the identity provider. Confirm which provider type fits each legacy system, since some older applications may only support LDAP or proxy sign-in, and document any exceptions in your risk analysis.

FreeIPA for Linux and UNIX estates

FreeIPA (GPL-3.0-or-later) provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. It fits servers and workstations that hold or reach ePHI and need central identity, host enrollment and consistent account lifecycle. The evidence it can support includes the KDC realm configuration, a list of enrolled hosts and the account disable or removal records. Confirm whether it meets your multi-factor expectations for interactive logins, because the factors available depend on the deployed version and any added components.

Keycloak for passkeys and one-time codes

Keycloak (Apache-2.0) supports two-factor authentication with passkeys, recovery codes and TOTP or HOTP codes from apps such as Google Authenticator or FreeOTP. Its one-time password policies and W3C WebAuthn settings can be configured per realm, which gives you exported realm settings as evidence of the factors you enforce. Check that recovery code handling and emergency access procedures are documented, since a weak recovery path can undo a strong primary factor.

Zitadel with Force MFA

Zitadel (AGPL-3.0-only) login policies support TOTP authenticator apps, U2F security keys, passkeys and one-time passwords sent by email or SMS. Administrators can enable Force MFA so every user, or only locally authenticated users, must register a second factor. The AGPL-3.0-only license requires legal review if you modify the software and offer it to users over a network, so involve counsel before deployment. Evidence includes the exported login policy showing Force MFA is on, and a report of users who have not yet registered a second factor.

Who does what for 164.312(d) authentication

The covered entity or business associate owns the authentication decision. No outside party can take over accountability for the Security Rule, so the organization must decide how people and systems prove who they are before they reach ePHI. That decision should follow from the organization's own risk analysis and from the access paths it actually runs, not only from the defaults a vendor ships with.

Authentication decision: Decide which systems, roles and remote access paths need stronger verification, and name the person who approves the method chosen for each.
Risk analysis link: Record each authentication option evaluated, the reason it was selected or deferred, and the key activities NIST SP 800-66 Rev. 2 describes for this standard, including determining applicability to current systems. See NIST SP 800-66 Rev. 2 for the full list.
Policy approval: Have leadership approve the written authentication policy, set a review cycle and keep the signed approval record.
Proposed rule watch: Track whether the January 2025 proposal to require multi-factor authentication on technology assets in relevant systems is finalized, and list which systems would need changes.
Ownership of exceptions: Document any system that cannot use a stronger method, with the compensating measure and the reviewer who accepted it.

Check that the risk analysis names every system that holds ePHI and that someone inside the organization can explain why each authentication method was chosen.

Where organizations fall short on 164.312(d) authentication

Most authentication gaps under 164.312(d) are not missing software. They are accounts, systems and decisions that sit outside the central sign-in process, or that were never written down. The cards below cover the gaps assessors most often find and the fix for each, with the proposed multi-factor requirement treated as a risk to plan for rather than a current mandate.

Shared and generic accounts

Shared logins such as a single clinic or nursing account used by several staff make it impossible to show that a person, rather than a password, was the one who accessed ePHI. The standard asks you to verify identity before access, so a shared credential fails that test on its face. Check the directory and application user lists for generic names like admin, front desk or reception. Replace each with a named account tied to one individual, and retire the shared credential once the named accounts are working.

Service accounts and API keys without owners

Service accounts, scripts and API keys often authenticate systems that hold ePHI, yet nobody is named as their owner and their secrets are never rotated. The standard covers entities as well as people, so these credentials need the same scrutiny as user logins. Build an inventory that lists each credential, its owner, the systems it reaches and its last rotation date. Set a rotation schedule in your risk management plan and store secrets in a vault rather than in configuration files.

Legacy applications that bypass the identity provider

Older clinical or billing applications often keep local user tables, so sign-in never reaches the central identity provider. Staff who leave the organization can keep working accounts in these systems long after directory access is removed. Ask each application owner whether sign-in is delegated to the central directory. Where it is not, place the application behind a proxy or connect it through a supported protocol, and document the exception and its compensating controls if a full migration is not feasible.

MFA on some users but not privileged or remote access

Many organizations enable a second factor for email or VPN users but leave administrators, vendors and remote sessions on password alone. Those are the paths attackers most often target and the accounts with the widest reach into ePHI. Confirm in your identity platform which groups have a second factor enforced, and check that administrative consoles, remote access and third-party access are included. Treat every exception as a documented decision with an owner and a review date.

No documented decision tied to the risk analysis

Authentication choices are often made during a system build and never linked back to the risk analysis. The standard requires you to determine which authentication applies to each system and to select options that fit it, so an undocumented choice is hard to defend. For each system holding ePHI, record the authentication method, the risk analysis finding that drove it, and who approved it. Keep these records with your Security Rule documentation so an assessor can trace the decision.

No review after system changes

Authentication settings drift when systems are upgraded, when a new application is added or when a vendor changes its sign-in flow. A configuration that was correct at go-live can silently allow password-only access later. Set a trigger list for review, covering upgrades, new integrations, staff role changes and vendor onboarding. Re-run the authentication check for each affected system and record the result. The proposed rule, if finalized as published in January 2025, would require multi-factor authentication on all technology assets in relevant systems, so plan for that requirement now by inventorying where a second factor is not yet possible.

Questions buyers ask about 164.312(d) authentication cost and effort

Does the HIPAA Security Rule currently require multi-factor authentication?

No. The current text of 164.312(d) requires procedures to verify that a person or entity seeking access to ePHI is the one claimed, but it does not name multi-factor authentication (MFA) as the method. The standard has no implementation specifications, so the organization chooses the method through its own risk analysis. Many organizations still adopt MFA for remote access, administrator accounts and email because it is a practical way to meet the standard. The January 2025 proposed rule would change this by requiring MFA on relevant systems, but that change is not final as of October 2026. Confirm the current text in the eCFR and the status of the rulemaking before you write a policy that cites it.

What drives the cost and effort of HIPAA authentication work?

The main drivers are the number of systems that hold or reach ePHI, how many identity sources exist today, and how many users, service accounts and devices need verification. Costs also rise when older applications cannot delegate sign-in to a central identity provider, when legacy directories must be migrated, and when staff need training on new login flows. Effort is mostly one-time setup and testing, followed by recurring work such as access reviews, account lifecycle tasks and monitoring of failed logins. Ask any provider to break its quote into discovery, configuration, integration, testing, documentation and handover, with ongoing support priced separately.

Can we handle 164.312(d) authentication in-house?

Often yes, if your team already runs directory services, identity management and application administration. The organization owns the decision and the evidence, so the work cannot be fully handed off. Internal teams usually need help when they lack experience with protocols such as OAuth2, OpenID Connect or SAML, or when many legacy applications need to be connected. Open-source identity providers such as authentik, FreeIPA and Keycloak can cover much of the technical work, but each needs a clear configuration baseline, secure hosting and documented procedures. Assess your team's skills against the scope before deciding.

What does the authentication work need from our staff?

It needs an identity owner who can make decisions, administrators who understand the applications that hold ePHI, and a security or compliance lead who can translate the risk analysis into requirements. Application owners must confirm which systems depend on local accounts and which can use central sign-in. Help desk staff need procedures for enrollment, lost devices and recovery codes. Users need short, clear guidance about new factors. Ask a provider which roles it expects from your side, how many working hours it assumes for each, and who signs off on access decisions.

Does an assessor certify that we comply with 164.312(d)?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and HHS does not endorse or recognize private certifications. A third-party assessment can test your controls and produce findings, but it does not create a HIPAA certificate, and it does not prevent OCR from later finding a violation. Your organization remains responsible for its own compliance. Ask any assessor what the report covers, what it does not cover, and what evidence supports each finding. Be wary of any provider that offers a HIPAA certificate.

How should we prepare for the proposed MFA requirement?

Start by inventorying every system that holds or transmits ePHI, including cloud services, remote access paths and administrator tools. Record which accounts currently sign in with passwords alone, and which can already use a second factor. Choose an identity approach that can support MFA across those systems, such as Keycloak, Zitadel or authentik, and test it in a non-production environment first. Document the exceptions you would need to justify under the proposal, and keep your risk analysis current. Track the rulemaking through the Federal Register and the Unified Agenda, because the final text may differ from the proposal.

When should we bring in an outside partner for authentication?

Consider a partner when your inventory shows many legacy applications, when administrator access must be redesigned, or when your team cannot meet the deadline set by your own risk management plan. A partner can plan the scope, configure and harden open-source identity platforms inside your environment, document the procedures and prepare evidence for your assessor. Most engagements are fixed-scope, so agree on the systems, deliverables and timeline in writing before work starts. DeployOpen prepares systems and evidence but does not issue audit reports or certifications, so independent assessors remain necessary if you need an external review.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source identity platforms inside your own infrastructure, then prepares the authentication configuration and evidence that a 164.312(d) review will look at. Your organization owns the risk analysis, the authentication decisions and the compliance position, and an independent assessor makes any determination.

How we scope

Written scope lists every application, API and user population that reaches ePHI and needs authentication.
Scope records the authentication options evaluated for each system, following the key activities in NIST SP 800-66 Rev. 2.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.

How we build

Deploy the chosen identity provider, such as authentik, Keycloak, Zitadel or FreeIPA, in your cloud account, data center or air-gapped network.
Connect ePHI applications to the identity provider and configure second-factor policies, including TOTP, passkeys or security keys where your decision requires them.
Test sign-in paths, failed-login handling and service account authentication, and record the results against the agreed scope.

How we hand over

Deliver configuration baselines, policy exports and an authentication inventory mapping each ePHI system to its method.
Document procedures for enrollment, recovery codes, credential revocation and periodic review, so your staff can run them without us.
Provide evidence packages that show what was configured and tested; the organization and its auditor decide whether they meet the standard.

How we support

Confirm with each vendor which authentication features your chosen version supports before committing to a configuration.
Review authentication settings when systems change, and track the January 2025 proposal against your configuration, since it is not yet final.
Ongoing upgrades, patching and continuous testing of authentication paths are available under a retainer agreed in writing.