IA-2 Identification and authentication: requirements and evidence

What IA-2 asks for and why an assessor starts with user accounts

If an audit or contract requires NIST SP 800-53, the question you will be asked is whether every person using your systems is uniquely identified and authenticated, and whether privileged access is protected by multi-factor authentication. IA-2 Identification and authentication (organizational users) is the control that answers it. It requires the system to uniquely identify and authenticate organizational users and to tie that identity to every process that acts on the user's behalf, so that a session, script or service call can be traced back to a person. The assessor starts with the account list because every other access and audit control depends on it: if accounts are shared, orphaned or accepted without strong authentication, logs and access reviews cannot prove who did what.

The control has two multi-factor enhancements that carry most of the weight. IA-2(1) requires multi-factor authentication for access to privileged accounts, and IA-2(2) requires it for non-privileged accounts. SP 800-53B selects both in the low, moderate and high baselines, so a low-impact system is still expected to use multi-factor authentication for its users. IA-2 is selected in the low, moderate and high baselines but not in the privacy baseline. Of its 13 numbered enhancements in Release 5.2.0, five are withdrawn, leaving 8 current enhancements, so confirm your assessment scope against the current catalog rather than an older copy. Shared or generic administrator accounts and password-only logins are the usual findings here, because they break individual accountability and leave the privileged path exposed.

Before you plan any tooling, export the full list of accounts from each system in scope, including service accounts, break-glass accounts and vendor access, and mark which ones are shared. For each account, record the authenticator type, whether multi-factor authentication is enforced and the owner who can explain the account. An open-source identity provider such as authentik, Keycloak, FreeIPA or Zitadel can centralize sign-in and enforce these settings, but the organization still owns the account decisions and the evidence. Ask your implementation partner to show, for a sample of accounts, the configuration that enforces multi-factor authentication and the logs that prove it. The independent assessor will test that sample, not your intentions.

Which accounts, systems and third parties fall under IA-2 scope

IA-2 applies to organizational users, so the first scoping decision is which accounts count as organizational users inside the system boundary. The impact baseline then decides which enhancements apply, and outside users move to a different control.

Organizational user accounts in the boundary

Start with the accounts that let staff, contractors and other organizational users act on the system: directory accounts, application logins, administrative consoles and remote access paths. Export the list of system accounts, since assessors examine that list and the audit records behind it. Confirm that each account maps to a named individual, and flag any account that cannot be tied to one person. Ask your identity team which sources feed the list, because accounts created outside the directory are a common gap.

Privileged versus non-privileged accounts

IA-2(1) requires multi-factor authentication for privileged accounts, and IA-2(2) covers non-privileged accounts. Both enhancements are selected at the low, moderate and high baselines, so every organizational user account needs a classification. Mark administrator, root, break-glass and service-management roles as privileged, and record the basis for each decision. Review the classification whenever roles change, because a role that gains administrative rights moves into the stricter enhancement.

Identity providers that broker sign-in

When applications delegate sign-in to a central identity provider, the provider becomes part of the IA-2 boundary even if the application is outside it. Document which applications use which provider, and which protocols connect them, such as OAuth2, OpenID Connect, SAML, LDAP or RADIUS. Confirm whether any application keeps local passwords that bypass the provider. Those local accounts stay in scope and need their own identification and authentication evidence.

Shared and group accounts at high baseline

IA-2(5) requires individual authentication before group authentication is allowed, and SP 800-53B selects it only at the high baseline. Shared administrator IDs, team logins and generic operator accounts therefore need a decision: retire them, or keep them and require each person to authenticate individually first. Inventory every group account, record its members and check whether the high baseline applies. At lower baselines, document the shared accounts anyway, because assessors still look for them.

Impact baseline and enhancement selection

The impact level of the system sets the baseline, and the baseline sets the enhancements. IA-2 applies at low, moderate and high, but IA-2 is not selected for the privacy baseline, so privacy-only scope does not pull it in. Confirm the categorization with the system owner before listing enhancements, and record any tailoring decision in the plan. Ask the assessor to confirm which enhancements apply to your categorization.

Outside users under IA-8

Members of the public, partner staff and users from other agencies are not organizational users, so IA-2 does not govern their sign-in. Their identification and authentication falls under IA-8, which has its own enhancements for accepting external credentials. Separate these populations in your account inventory and in the identity provider configuration. Mixing them in one directory group is a frequent cause of scoping errors that surface during assessment.

How an assessor tests IA-2 under SP 800-53A

This table maps each assessment method SP 800-53A uses for IA-2 to the objects the assessor examines, interviews or tests, the evidence to prepare, and where findings usually arise. Read it as a preparation checklist: the two determination statements are the questions the assessor must answer, and each row shows what proves the answer.

Assessment method	What the assessor looks at	Evidence to prepare	Common finding
Examine: list of system accounts	Every account that can sign in to the system, including human, shared and emergency accounts	Complete account export with owner, account type and last login; reconciliation against HR or directory records	Shared administrator accounts with no individual owner recorded
Examine: system audit records	Whether sign-in events tie to a unique user identifier and show the authentication method used	Sample of authentication logs covering privileged and non-privileged accounts over a defined period	Logs show generic or group names, so individual activity cannot be traced
Interview: system operations personnel	How staff uniquely identify and authenticate, and how they handle exceptions	Named interviewees, their roles and a walkthrough of a real sign-in and an account request	Staff describe a workaround that bypasses the standard sign-in path
Interview: system and network administrators	How privileged access is granted, multi-factor authentication enforced and break-glass accounts controlled	Written privileged access procedure and the MFA enforcement settings the administrator can demonstrate	Administrators say MFA is optional for some consoles or service paths
Test: processes for unique identification and authentication	Whether the documented process works in the live system, from account creation to sign-in	Test accounts created and tested, plus screenshots or configuration exports of identity provider policies	Process documented but not enforced, or enforced for some applications only
Determination statement 1: unique identification	Each organizational user is uniquely identified, and that identity is linked to processes acting for them	Mapping of user identifiers to processes and service actions taken on the user's behalf	Processes run under a shared identity, breaking attribution of actions
Determination statement 2: authentication	Users are authenticated, with MFA for privileged and non-privileged access as selected by the baseline	MFA enrollment report and enforcement policy, with documented approval for any exception	MFA exceptions exist without documented approval or an expiry date

Implementing IA-2 from account inventory to MFA enforcement

This sequence turns IA-2 from a policy statement into a verified state in which every organizational user has one traceable identity, every account class is covered by the multi-factor authentication the baseline selects, and every gap is either closed or formally documented as an exception.

Inventory every account and classify privilege
The system owner, with the identity team, lists every account that can authenticate to in-scope systems, including directory accounts, local accounts on servers and network devices, service-linked identities and vendor accounts. Each account is tagged as privileged (administrative or security-relevant functions) or non-privileged, and tagged with its owner. The output is a reviewed account list that a assessor can compare against the system's authorization boundary. Confirm the classification criteria with your own security team, since IA-2(1) and IA-2(2) depend on it.
Choose the authoritative identity source
Decide which directory or identity provider is the source of truth for organizational users, and which systems will delegate sign-in to it. Candidates include authentik, which brokers OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy access for applications, FreeIPA, which provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, and Keycloak or Zitadel for application-level federation. The architecture decision, owner and integration map are documented in the system security plan. The output is a diagram showing which systems authenticate against which source, with local accounts reduced to documented break-glass exceptions.
Enforce unique accounts and remove shared logins
Every person gets one account that is bound to a single identity in the source directory, and the system associates that identifier with every process the user starts. Shared administrator accounts, generic logins and credentials stored in scripts are identified from the inventory and retired or converted into named accounts with individual accountability. The identity team confirms this with a directory query and a sample of audit records that tie actions to individual identities. The output is a list of retired shared accounts and the reconciled directory export that proves one identity per person.
Enforce multi-factor authentication for privileged accounts
The identity administrator configures the identity provider so that privileged accounts must present a second factor for every interactive sign-in, which is the requirement behind IA-2(1). Options include TOTP apps, U2F or FIDO2 security keys, and passkeys, all of which the open-source platforms above can support, as described in each product's documentation. Enforcement is tested with a privileged test account that is denied access without the second factor. The output is a policy export, a test record for each privileged system and a screenshot or log entry showing a denied attempt.
Enforce multi-factor authentication for non-privileged accounts
The same process applies to non-privileged accounts for IA-2(2). The identity owner sets a login policy that requires a second factor for all users or for the subset that signs in locally, and confirms that federated applications inherit the policy instead of accepting a single-factor session. Keycloak supports passkeys, recovery codes and configurable one-time password policies, and Zitadel offers a Force MFA setting for all users or locally authenticated users. The output is a per-application coverage table that shows the second factor is enforced at each sign-in path.
Configure replay-resistant and PIV options where selected
Where the chosen baseline selects IA-2(8) for replay-resistant access to accounts, the team confirms that the authentication mechanisms resist capture and reuse of authenticator output, for example through challenge-response or public-key methods. Where IA-2(12) applies, the team confirms that the system accepts PIV credentials issued by a trusted authority and documents which federal credentials are accepted. High-baseline systems also review IA-2(5) for shared group accounts. The output is a configuration record for each enhancement and a test showing that a captured one-time code cannot be replayed. Ask your assessor which of these enhancements the chosen baseline requires for your system.
Document exceptions and assemble assessment evidence
Any account that cannot meet MFA or unique identification, such as a legacy appliance or an emergency account, is recorded as an exception with its owner, compensating controls, a review date set by the organization and an approval record. The control narrative in the system security plan is updated to match the implemented state, and evidence is gathered for each assessment method the SP 800-53A procedure uses: the account list, policy exports, test results and interview notes. The output is an exception register and an evidence package that an independent assessor can review. The organization owns the control and its exceptions, and the assessor issues the findings.

Choosing a self-hosted identity provider for IA-2

authentik acts as an identity provider that applications delegate sign-in to. Rather than each application keeping its own user store, the applications send users to authentik, which then issues the assertion or token the application trusts. For IA-2, this centralizes the place where individual accounts are identified and where MFA enforcement is configured. The project is licensed under MIT.

Protocol coverage: authentik documents provider types for OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, which helps when legacy and modern applications need to sign in through the same service.
Proxy providers: Applications without native federation support can be placed behind authentik, so sign-in is enforced at the front of the application.
Central accounts: Each person has one identity record, which supports the unique identification part of IA-2 when applications share it.
Application inventory: Your team must list every application and confirm which provider type each one uses, since an application that keeps local passwords falls outside the central control.
Operations: The team that runs authentik will own its availability, backups and upgrades, because sign-in for every connected application depends on it.

Confirm with the environment that every protocol you need is supported for your versions of the applications, and that MFA enforcement in authentik applies to the sign-in paths your users take.

Evidence that passes IA-2 and how to keep it current

An assessor testing IA-2 wants to see who the accounts belong to, how the identity provider enforces multi-factor authentication, and whether that enforcement held over the audit period. The cards below cover the artifacts that show this, how often each should be refreshed between assessments, and which role should own it.

Account inventory of organizational users

Export the full list of user accounts from the directory or identity provider, with each account tied to a named person, account type and status. Assessors compare this list against HR records and the access lists for each system to confirm that every account is unique and that shared or generic accounts are identified. Refresh the export at least once per assessment cycle and after any bulk onboarding or offboarding. The identity administrator owns the export, and the system owner signs off on the reconciliation.

Identity provider configuration exports

Keep dated exports of the identity provider settings that govern sign-in, including password policy, MFA requirements, session lifetimes and which applications delegate authentication to it. Keycloak, Zitadel and authentik each expose these settings in their administration consoles, and the exports should be stored under version control so changes are traceable. Re-export after every configuration change and at the start of each assessment. The platform engineer owns the exports, and the security team reviews them.

MFA enforcement policy evidence

Capture the configuration that requires a second factor for privileged and non-privileged accounts, such as a Zitadel Force MFA setting or the Keycloak OTP and WebAuthn policies. Screenshots are weaker than exported configuration, so pair each screenshot with the config file or API response it came from. Confirm the scope covers every application in the inventory, not only the one the team tested. The identity administrator owns this evidence and records any change in the change log.

Authentication logs across the audit period

Collect sign-in logs that show the user identity, timestamp, authentication method and result for successful and failed attempts. Assessors sample these logs to confirm that MFA events occurred for the accounts in scope and that failures are recorded. Export logs on a fixed schedule into write-once storage so the record survives administrator changes. The security operations team owns retention and sampling support, and log retention periods should follow the organization's audit policy.

Exception records with approvals

Document every account or application that cannot enforce MFA, along with the business reason, compensating control, expiration date and the approver's name. An undocumented exception is treated as a failed control, so the register must match what the directory shows. Review open exceptions at least once per assessment cycle and close any that the business no longer needs. The control owner approves exceptions, and the compliance lead maintains the register.

Negative test results for non-MFA login

Run a scripted test that attempts a password-only sign-in for a sample of privileged and non-privileged accounts and record that each attempt is refused. Save the test script, the date, the accounts tested and the output, then repeat the test after any identity provider upgrade or policy change. This artifact shows the control works in practice rather than only on paper. The security engineer runs the test, and an independent reviewer should witness at least one run.

What meeting IA-2 costs in money and effort

This table breaks down the cost and effort components of meeting IA-2 for organizational users, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are given because none were supplied, so use it to build the scope you request in writing from vendors and partners before asking for a quote.

Cost component	One-time or recurring	Who is paid	What drives it
Identity platform licenses or self-hosting effort	Recurring if licensed, mostly one-time build plus upkeep if self-hosted	Software vendor, or internal staff and an implementation partner for self-hosted deployments	Number of users, hosting model, high availability design, and whether the platform is open source and self-maintained
Engineering time to integrate applications	One-time per application, with occasional recurring changes	Internal platform or application teams, or an implementation partner under a fixed scope	Number of applications, protocol mix (OIDC, SAML, LDAP, RADIUS, proxy), and legacy systems that need custom work
MFA enrollment and hardware tokens or passkey rollout	One-time rollout, recurring replacement and help desk support	Organization for token purchases, help desk staff, and user time during enrollment	Count of privileged and non-privileged users, choice of TOTP, security keys or passkeys, and lost-device volume
Privileged account MFA configuration and testing	One-time configuration, recurring review	Internal identity and security engineers, with partner support if scoped	Number of privileged paths, break-glass procedures, and how many systems accept only local accounts
Evidence upkeep	Recurring	Internal control owners, supported by tooling exports and configuration records	How often access reviews, configuration exports and authentication logs are collected, and how automated the collection is
External review of the IA-2 design	One-time or periodic	Independent assessor or consultant, selected and paid by the organization	Scope of systems in the boundary and whether the design is reviewed before or after deployment
Auditor sampling and testing	Recurring with each assessment cycle	Independent auditor or assessor, paid by the organization	Sample sizes chosen by the assessor, number of systems in scope, and the quality of ready-made evidence

How self-hosted open-source identity tools produce IA-2 evidence

An identity provider running inside the client's own environment can generate much of the evidence an IA-2 assessment asks for: the list of system accounts, the record of which accounts require a second factor, and authentication event logs that tie each sign-in to a unique user. The organization still owns the control. The identity provider is a tool that enforces and records it, and the assessor will test whether the organization's process for uniquely identifying and authenticating users actually works. Before any capability is claimed in an assessment package, confirm it in the client's deployment, not only in vendor documentation.

Three candidates illustrate the range. authentik can act as the identity provider for applications over OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so sign-in for those applications is delegated to one place. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, which fits hosts that need to authenticate against a central directory. Keycloak supports passkeys, recovery codes and TOTP or HOTP codes, with configurable one-time password policies, and Zitadel's login policies can enable Force MFA for every user or only for locally authenticated users. The decision is which provider covers which applications, and whether any application still accepts shared or local accounts that bypass it. Those gaps are usually where an assessor finds IA-2 weaknesses.

Ask the team to produce, from the running system, an export of the account list, a report of MFA enrollment and enforcement for privileged and non-privileged accounts, and a sample of authentication logs for a defined period. Check that each log entry can be traced to one named individual, and that break-glass or service accounts are documented as exceptions with their own controls. Confirm the log retention period and where logs are stored, because the assessor will need to see them without relying on the operator's word. Each of these checks should be confirmed for the specific product version and configuration in use, since the exact reports and log fields differ between platforms and deployments.

Where IA-2 implementations usually fall short

Most IA-2 gaps are not missing technology. They are accounts, applications and exceptions that sit outside the identity process the organization describes in its documentation. An assessor who samples the account list, the application inventory and the exception register will usually find these gaps first.

Shared and generic admin accounts

IA-2 asks the system to uniquely identify and authenticate organizational users and to tie that identity to the processes they start. A shared account such as a generic root or administrator login breaks that link, because the audit trail shows the account name, not the person. Check whether any administrative credential is used by more than one person, whether privileged users sign in under individual identities before elevating, and whether the shared credential is vaulted with checkout records. Closing action: replace each shared admin login with named accounts and confirm the audit records resolve to one person.

MFA applied to some applications only

IA-2(1) and IA-2(2) require multi-factor authentication for privileged and non-privileged accounts, and SP 800-53B selects these enhancements at the low baseline. Coverage often stops at the portal or the main application, while older tools, internal dashboards and API consoles still accept a password alone. Build an inventory of every application that authenticates users, then check which ones delegate sign-in to the central identity provider and which ones keep local accounts. Closing action: map each application to its identity source and mark every password-only sign-in as a finding.

Unmanaged MFA exceptions

Exceptions tend to appear when a user cannot enroll a second factor, when a legacy client cannot prompt for one, or when an executive asks for a bypass. Each exception weakens IA-2 for the account it covers, and the exception rarely has an owner, an expiry or a compensating control. Check whether exemptions exist in identity provider policies, conditional access rules and application settings, and whether each one is approved, time-limited and reviewed. Ask for the exception register and compare it against the live policy configuration. Closing action: require a named owner, an expiry date and a compensating control for every MFA exemption.

Service accounts treated as users

Service accounts and automation identities cannot complete an interactive second factor, so teams often exempt them from MFA or give them human-style passwords that never rotate. IA-2 is written around organizational users, so these identities need a separate design. They are usually better handled through the service identification and authentication controls (IA-9) and authenticator management (IA-5), with credentials bound to the workload. Check whether service accounts appear in the user directory, whether anyone knows their owners, and whether any of them hold interactive logins. Closing action: separate non-person identities from user accounts, assign each an owner and confirm no service account can sign in interactively.

No evidence of replay-resistant options

IA-2(8) asks for authentication that resists replay, and IA-2(12) concerns acceptance of PIV credentials. Many organizations use one-time codes sent by SMS or typed from an app, which can be phished and relayed, and they cannot show whether phishing-resistant options exist. Check which factor types each privileged group can use, whether FIDO2 or WebAuthn security keys and passkeys are offered, and whether PIV or CAC is accepted where the organization must accept it. Keycloak supports passkeys and WebAuthn settings, and Zitadel supports U2F security keys and passkeys, so the configuration can be confirmed from the product. Closing action: document which factors resist replay for each privileged group and export the policy that enforces them.

Who owns IA-2, who prepares the evidence and who assesses it

The organization owns IA-2. That means the organization decides who is an organizational user, which identity source is authoritative, which accounts are privileged, and which multi-factor methods are acceptable for each population. Those decisions are accountable to leadership and must be documented in the system security and privacy plan. Internal staff also run the day-to-day work that keeps the control true after go-live.

Account authority: HR or the identity team confirms who holds an account, and joiner, mover and leaver steps are executed by people the organization employs.
Privileged account scope: The security team names which administrator and service roles count as privileged so that IA-2(1) applies to the right accounts.
Policy decisions: Leadership accepts or rejects residual risk, such as exceptions for legacy applications that cannot accept a second factor.
Operational ownership: Staff review sign-in logs, handle lockouts and respond to suspected credential misuse.
Evidence custody: The organization keeps the account listings, configuration exports and review records that an assessor will ask to see.

Before engaging anyone, confirm internally which team signs the control narrative and who will answer assessor interview questions.

IA-2 questions buyers ask before hiring help

How much effort does IA-2 take to implement?

Effort depends mostly on how many user populations, applications and identity sources the system has, and on how much of the login path already enforces multi-factor authentication. IA-2 itself is a short control, but its enhancements touch every privileged and non-privileged account, so the work is in inventory and coverage rather than in writing the control statement. Ask a partner to break the effort into identity source mapping, MFA enrollment and enforcement, PIV handling if it applies, and evidence collection. No duration figure is given here, so confirm any estimate against your own environment and the written scope.

Can a small team implement IA-2 without outside help?

A small team can implement IA-2 if it owns the identity source, can enforce MFA centrally, and has someone who can document how accounts are created, disabled and reviewed. The harder parts are usually consistent MFA across every application, unique account handling for shared or service-style access, and producing evidence an assessor can test. Outside help is most useful when the team has many legacy applications, no single identity provider, or no capacity to build the evidence set alongside daily operations. DeployOpen prepares systems and evidence for assessments, but the organization owns its controls and an independent assessor issues any result.

What does the client need to provide for an IA-2 engagement?

The client usually provides access to the systems in scope, a list of account stores and applications, the current policy on authentication and MFA, and named owners for identity and privileged access. Engineers also need the authentication configuration for each application and a sample of account records to test uniqueness. Access should be granted in the client's own infrastructure, and the client keeps decision rights over which accounts are in scope. Confirm these inputs in the written scope before work starts, because gaps in account inventories are the most common cause of delay.

Does IA-2 differ by baseline in SP 800-53B?

Yes, the baseline changes which enhancements are required. SP 800-53B Release 5.2.0 selects IA-2 for the low, moderate and high baselines but not for the privacy baseline. The low, moderate and high baselines select IA-2(1) and IA-2(2) for multi-factor authentication, IA-2(8) for replay-resistant access, and IA-2(12) for acceptance of PIV credentials. Only the high baseline also selects IA-2(5) for individual authentication with group authentication. Check the exact selections against the current OSCAL baseline profiles, since the system's impact level determines which baseline applies.

Does IA-2 require a centralized identity provider?

IA-2 does not name a specific product or require one identity provider, but a central provider is the practical way to enforce unique identification and MFA across many applications. Without one, each application needs its own account store and MFA settings, which makes consistent evidence harder to produce. Open-source options include authentik, which provides OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers for applications, FreeIPA for single sign-on in Linux and UNIX environments through an MIT Kerberos KDC, Keycloak for passkeys, TOTP and HOTP with configurable one-time password policies, and Zitadel for login policies that can force MFA for all users. Confirm which protocols and features each product supports for your applications before choosing one.

Who issues the IA-2 assessment result?

An independent assessor issues the assessment result, not the implementation partner and not NIST. SP 800-53A provides the assessment procedures for IA-2, including its determination statements and examine, interview and test methods, and the assessor applies them to the system. Under FISMA for federal systems, Inspectors General independently assess agency security, and other programs name their own assessor types. DeployOpen prepares systems, controls and evidence for that assessment but does not issue audit reports, attestations or certifications. Ask any partner to confirm in writing which party will perform the assessment and what the assessor needs from the evidence package.

What does an IA-2 assessor actually test?

An assessor typically examines the list of system accounts and audit records, interviews personnel who run system operations and administration, and tests whether the organization's processes uniquely identify and authenticate users. SP 800-53A lists these objects for IA-2 under its examine, interview and test methods. Evidence that passes usually includes an account inventory showing one identifier per person, MFA configuration exports for privileged and non-privileged access, and logs showing authentication events tied to individual accounts. Ask your partner to map each assessment object to a specific artifact before evidence collection begins.

How DeployOpen scopes and prepares IA-2 evidence

DeployOpen plans, implements and documents self-hosted open-source identity platforms inside your own infrastructure, so that unique user identification and multi-factor authentication for IA-2 are configured and recorded in a form an assessor can test. We prepare the systems and evidence; your organization owns its controls, and only an independent assessor issues findings.

How we scope

Engagements are fixed-scope, with the IA-2 systems, user populations and enhancements agreed in writing before work starts.
The written scope names which applications delegate sign-in to the identity provider and which accounts count as privileged.
We confirm with you which SP 800-53B baseline applies, since IA-2 enhancements differ between the low, moderate and high baselines.

How we build

We configure unique accounts, group-free sign-in and MFA enforcement for privileged and non-privileged users in your environment.
We test replay resistance and PIV or other credential acceptance where the agreed scope requires them, and record the results.
We integrate applications with the identity provider, such as authentik, Keycloak, FreeIPA or Zitadel, depending on your selection.

How we hand over

We deliver configuration records, account lists and MFA policy exports that map to the examine objects an assessor will request.
We document interview-ready procedures for administrators covering account creation, enrollment and removal of second factors.
We hand over evidence packages and a list of open items, while the independent assessor decides whether IA-2 is met.

How we support

Ongoing support, upgrades and continuous testing of the identity platform are available as retainers after handover.
Retainers can cover re-running MFA and account evidence collection before each assessment cycle.
Changes to scope, such as new applications or a higher baseline, are agreed in writing before further work begins.