What NIST SP 800-53 IA-2 asks for in open source MFA
If you own a federal system, IA-2 is the control that asks whether every organizational user is uniquely identified and authenticated, and whether privileged and non-privileged accounts both need a second factor. The control's two core enhancements, IA-2(1) for privileged accounts and IA-2(2) for non-privileged accounts, require multi-factor authentication. Under SP 800-53B Release 5.2.0, IA-2 applies to the low, moderate and high baselines but not to the privacy baseline, so the first scoping decision is your system's impact level. The release lists 13 numbered enhancements for IA-2, but IA-2(3), IA-2(4), IA-2(7), IA-2(9) and IA-2(11) are withdrawn, which leaves 8 current enhancements. Start from the current list in the NIST CPRT catalog, not from older guidance that cites withdrawn items.
Replay resistance is the enhancement that most often separates an OTP setup from a compliant design. IA-2(8) asks for replay-resistant access to accounts, and the baselines also select IA-2(12) for acceptance of PIV credentials. IA-2(5), group authentication, applies only in the high baseline. A self-hosted privacyIDEA, Keycloak or FreeIPA deployment can cover these, but the decisions are yours: which token types count as replay resistant for each population, whether PIV or smartcards are accepted at all, and how shared or group accounts are handled. Confirm each token type against the current IA-2 text with your assessor before enrollment begins.
IA-2 is a design and evidence requirement, not a product you buy. NIST does not offer or endorse compliance tools, and it leaves federal implementation timelines to OMB Circular A-130. Your authorizing official and independent assessors judge whether the control is implemented and assessed using SP 800-53A procedures. DeployOpen can prepare the configuration, the account mapping and the evidence set for that review, but it does not issue assessment results or certifications. Ask any implementation partner to show how each enhancement maps to a configuration item, a test and a log source before scoping begins.
How each IA-2 requirement maps to self-hosted MFA configuration
This table maps each IA-2 element in scope for this page to the function the platform must perform and the configuration an operator would set in privacyIDEA, Keycloak or FreeIPA. Read each row as a design question to answer with your own system owners, since the platform configuration establishes capability but does not by itself satisfy the control. The main takeaway is that unique identifiers, MFA enforcement scope and factor selection each need an explicit configuration decision and a recorded owner.
| Requirement | What the platform must do | Configuration to define and evidence |
|---|---|---|
| IA-2 base control (organizational users) | Uniquely identify and authenticate each organizational user and tie that identity to processes acting on the user's behalf | Use one directory identifier per person in privacyIDEA user ID resolvers (LDAP, SQL or SCIM) or FreeIPA, and disallow shared logins for interactive access |
| IA-2(1) MFA for privileged accounts | Require a second factor for every privileged account on every path that grants privilege | Enforce MFA policies for admin groups in Keycloak or privacyIDEA, covering consoles, SSH and sudo, and record which policy applied to each login |
| IA-2(2) MFA for non-privileged accounts | Require a second factor for standard user access to the systems in the authorization boundary | Scope the MFA policy to all user groups across VPN, Windows, Linux and web applications, and list any exception with its owner and expiry date |
| IA-2(5) Individual authentication with group authentication (high baseline only) | Where a group account is used, require each member to authenticate individually before the group session is granted | Confirm the platform records the individual identity behind any shared session, and document which group accounts exist and who may use them |
| IA-2(8) Replay-resistant access to accounts | Prevent a captured one-time code or authenticator response from being reused to log in | Prefer FIDO2 or WebAuthn keys and passkeys, which are challenge-based, and confirm whether time-based OTP replay checks are enabled in the chosen version |
| IA-2(12) Acceptance of PIV credentials | Accept PIV credentials issued under HSPD-12 as an authentication factor for organizational users | Configure smartcard or x509 certificate validation in privacyIDEA or Keycloak, including trust chain and revocation checks, and test with real issued cards |
Which IA-2 enhancements apply at each impact level
IA-2(1) and IA-2(2) are the enhancements most teams will be asked about first. SP 800-53B Release 5.2.0 selects IA-2(1), which requires multi-factor authentication for privileged accounts, and IA-2(2), which requires it for non-privileged accounts, in the low, moderate and high baselines. IA-2(8), replay-resistant access to accounts, and IA-2(12), acceptance of PIV credentials, are also selected at all three impact levels. IA-2(5), individual authentication with group authentication, is selected only in the high baseline. The privacy baseline does not select IA-2 at all. For a self-hosted design, this means that a low-impact system still needs MFA for both privileged and non-privileged users, while the replay resistance and PIV questions become mandatory as soon as the system is categorized at any level.
Before you scope the MFA project, confirm the impact categorization of each system with the authorizing official and the security team, then pull the exact baseline from NIST's OSCAL profiles for SP 800-53B. Tailoring can remove or modify selected enhancements, and overlays can add requirements for specific environments. Ask the authorizing official whether any overlay in NIST's Security Control Overlay Repository applies to the system and whether IA-2(5) needs to be addressed for shared or group accounts at high impact. Those answers decide whether a privacyIDEA or Keycloak deployment must support PIV smartcards and replay-resistant tokens, or whether FIDO2 and OTP are sufficient for the scope.
The OSCAL profile counts are useful context, since they show how much larger the high baseline is than the low baseline, but they are not a substitute for a scoping decision. Counting base controls and enhancements together, NIST's profiles select 149 items for low, 287 for moderate and 370 for high. Treat those figures as a planning signal only, and confirm the final control list in writing before procurement or a DeployOpen scope is agreed, since the inherited and system-specific control allocations will change what the MFA platform itself must evidence.
Which open-source platforms fit IA-2 enforcement
IA-2 is satisfied only where every organizational login path passes through an identity provider that enforces MFA for both privileged and non-privileged accounts. The three platforms below cover different layers of that path: a dedicated MFA server, a web single sign-on broker, and a directory that can hold OTP credentials. Most federal designs combine them, so the choice depends on which login paths you must cover first.
privacyIDEA as the MFA server
privacyIDEA covers the widest token range in this group, including FIDO2 and WebAuthn, PIV and x509 smartcards, push, TOTP and HOTP. It reaches Linux through a PAM module, Windows logon through a credential provider, and VPNs through RADIUS, so one enforcement point can serve many login paths. Check which token types your assessment requires, whether you need hardware token seed import for HOTP or TOTP tokens, and how the RADIUS and PAM paths behave when the server is unreachable. The project is AGPLv3 licensed, and the Enterprise Edition is available from NetKnights.
Keycloak for web app enforcement
Keycloak enforces MFA for web applications through OpenID Connect and SAML 2.0 flows, with user federation to LDAP and Active Directory. It suits applications that accept standard federation, while legacy systems without these protocols still need a proxy or a privacyIDEA integration. Keycloak is Apache-2.0 licensed and ships on a frequent cadence, so plan an upgrade process with a test environment and confirm which minor release your assessment baseline references. Its supported production databases, clustering design and Operator update approval mode all affect the evidence you keep.
FreeIPA for directory-backed OTP
FreeIPA combines an LDAP directory, Kerberos and a certificate authority, and it can store OTP credentials for users. This makes it a practical choice where the directory is the system of record for organizational users and Linux SSH and sudo logins must follow central policy. Confirm that FreeIPA's OTP and RADIUS options meet your token requirements, because it covers fewer token types than privacyIDEA. Its directory role also means its availability and backup design affect every login that depends on it.
Database and high availability design
Keycloak supports several production databases, including PostgreSQL 14 to 18, and documents high availability designs that require a synchronously replicated database. Losing the database or breaking replication can lock out privileged users, so the database tier is part of the IA-2 control boundary. Confirm the supported database versions, the replication mode and how your backups are tested. Keep in mind that the dev-file database is for development only.
Operator update and schema migration
Keycloak can run on Kubernetes through the Keycloak Operator, which the project's documentation recommends installing through Operator Lifecycle Manager. The Operator documentation strongly recommends manual approval mode for updates to avoid unintended upgrades. Keycloak also migrates its database schema automatically at startup by default, and manual migration is available for large deployments. Record which approval mode, migration method and release version each change used, because those records become the change evidence an assessor will ask for.
Release cadence and change control
Since Keycloak 26.0, the project plans four minor releases a year, and it states that breaking changes in a minor release will be opt-in. That makes release cadence a planning input for IA-2 evidence: each upgrade changes configuration, login flows and possibly the MFA behavior your assessors tested. Keep a documented baseline version, a test cycle for each release and a rollback plan. Ask your partner to confirm how privacyIDEA and FreeIPA releases will be tracked in the same change process.
Choosing a platform for privileged versus non-privileged access
IA-2(1) requires multi-factor authentication for privileged accounts, so administrative logins are the first population to cover and the one with the least room for exceptions. Administrative access usually spans SSH to Linux hosts, RDP or console logon to Windows servers, and privileged consoles in web applications. A single self-hosted MFA service can cover these paths, but each path needs its own integration and its own test. Privileged accounts also tend to be the ones with break-glass and service exceptions, which must be documented rather than left implicit.
- Scope of privileged accounts: Build an inventory of accounts with administrative rights, including local and directory-based admin groups, before choosing the integration order.
- Break-glass accounts: Document how emergency accounts are protected, who holds them and how their use is logged and reviewed.
- Console and out-of-band paths: Confirm whether the MFA service is reachable from the management network if the normal path fails.
- Service accounts: Separate human privileged logins from automation accounts that cannot prompt for a second factor.
Confirm with your assessor which privileged paths they will sample and how they expect exceptions to be recorded.
IA-2(2) applies the same multi-factor requirement to non-privileged organizational users, which in most environments means the broad workforce. The main design question is scale: enrollment, help desk load and recovery matter more here than for administrators, and the token mix often needs to include standard authenticator apps alongside hardware keys. Coverage tends to start with remote access and email, then expand to internal applications. Each user store (directory, identity provider or SQL source) must map cleanly to the unique identifiers the MFA service uses.
- Enrollment path: Decide whether users self-enroll, enroll at a help desk or receive pre-provisioned tokens, and document each route.
- Token mix: Confirm which token types your policy permits for standard users, such as TOTP, push or FIDO2.
- User store mapping: Confirm that the directory or resolver returns a stable unique identifier for each user.
- Recovery: Define how lost tokens are replaced and how identity is verified before a replacement is issued.
Confirm with the platform team how many users each integration path will serve and whether the help desk has a documented replacement procedure.
VPN gateways commonly authenticate through RADIUS, and privacyIDEA can act as the RADIUS server that validates the second factor for OpenVPN, Fortinet and Palo Alto gateways. This path tends to carry both privileged and non-privileged remote access, so the same MFA service must apply the right policy to each group. Because a RADIUS outage can lock out remote staff, the design must include redundancy and a tested failure mode. FreeIPA is another option for the user store behind the RADIUS path, depending on your directory.
- privacyIDEA as RADIUS server: Confirm the gateway models and firmware you run support the RADIUS challenge flow you need.
- Policy by group: Use separate policies for administrator and standard VPN groups so privileged remote access can require stronger token types.
- Failover: Confirm how the gateway behaves when the primary RADIUS server is unreachable and whether a second server is configured.
- Logging: Confirm that gateway and MFA logs record the user, the token used and the result for each attempt.
Confirm each gateway's RADIUS behavior in its vendor documentation and test failover before go-live.
Operating system logons are where privileged and non-privileged access diverge most sharply. On Linux, privacyIDEA provides a PAM module that can protect SSH and sudo, and FreeIPA offers OTP for centrally managed hosts. On Windows, the privacyIDEA credential provider adds a second factor at desktop, server and RDP logon. Administrator accounts generally need protection first, and offline logon for laptops is a separate design decision that affects who can be locked out.
- Linux PAM path: Confirm the PAM module version against your distribution and test SSH and sudo separately, since they can use different PAM stacks.
- Windows credential provider: Confirm the provider's supported Windows versions and how it handles RDP and console logons.
- Offline logon: Decide whether laptops may log on without reaching the MFA service, and document the limits.
- Central versus local policy: Prefer central policy and confirm which hosts can reach the MFA service.
Confirm supported operating systems and PAM or credential provider versions with the project and your own test results before scheduling rollout.
For web applications, Keycloak is commonly the broker that issues tokens to applications over OpenID Connect or SAML 2.0 and enforces a second factor in the authentication flow. Keycloak supports WebAuthn and OTP credentials and can federate users from LDAP or Active Directory, which keeps the identity source in place. Administrative consoles and high-value applications can be bound to a stricter authentication flow than general applications. Keycloak's own high availability design and database requirements must be planned before it becomes the single entry point for many systems.
- Client-level flows: Assign stronger authentication flows to administrative applications and standard flows to general ones.
- Federation: Confirm which directory attributes Keycloak reads and how it maps them to users.
- High availability: Confirm the synchronously replicated database and cluster design Keycloak needs for your availability target.
- Upgrades: Plan operator update approvals and schema migration as part of change control.
Confirm with your application owners which web systems will authenticate through Keycloak and which will keep a separate login during transition.
How to roll out IA-2 MFA in a federal environment
This sequence moves IA-2 from a control statement to a working, assessable MFA configuration, starting with the baseline and ending with a recorded configuration that an assessor can examine. Each step closes with an artifact that proves the previous step is complete.
Confirm the baseline and enhancements in scope
The security team and the system owner confirm the impact level of the system, which determines whether IA-2 applies under the low, moderate or high baseline, and then list the IA-2 enhancements that baseline selects. For IA-2(1), IA-2(2), IA-2(8) and IA-2(12), this is the set the design must satisfy. For IA-2(5), confirm whether the high baseline applies. Use the current SP 800-53B profile for Release 5.2.0 rather than an older copy. The output is a signed control scope statement that names each enhancement, the systems it covers and the agency owner who accepts it. Do not carry forward withdrawn enhancements from older documents.
Build the user ID source from the authoritative directory
Connect the MFA platform to the directory that is the system of record for organizational users, such as Active Directory or FreeIPA, using a read path that privacyIDEA supports through its LDAP, SQL, SCIM or HTTP user ID resolvers, or Keycloak through LDAP or Active Directory federation. Map each user to a unique identifier and confirm that shared or group accounts are excluded or handled under a documented exception, since IA-2 requires unique identification of organizational users. The identity team checks sample accounts end to end. The output is a resolver configuration and a test log showing that each sampled user resolves to exactly one identifier.
Enroll privileged accounts first
Require MFA for administrative and other privileged accounts before any other population, because IA-2(1) addresses these accounts directly and they carry the highest impact if compromised. The platform team enrolls each privileged user with a factor approved for the environment, and the help desk verifies identity through an in-person or documented process before issuing or registering a token. Enrollment records, token serials and approval tickets are kept with the account. The output is a list of privileged accounts that show an enrolled factor and a policy that rejects logins from those accounts without a second factor.
Enforce MFA for non-privileged accounts
Extend the same policy to all other organizational users under IA-2(2), in waves that match business systems and access paths, such as VPN, email, web applications and remote desktop. Each wave runs in a pilot group first, with the help desk tracking failed enrollments and lockouts. Confirm that password-only authentication is removed from each in-scope path, not just added as an option, because an alternative path can defeat the control. The output is a coverage matrix that lists each access path, its MFA status and the date of enforcement, which the assessor will compare against the system boundary.
Configure replay-resistant factors for account access
Select factors and protocols that satisfy the replay resistance expected under IA-2(8), such as FIDO2 or WebAuthn security keys and passkeys supported by privacyIDEA or Keycloak, and confirm which OTP and push methods the platform allows and how their timing and reuse are controlled. Test that a captured one-time code cannot be submitted a second time and that a signed challenge cannot be reused. For IA-2(12), confirm whether PIV credentials are accepted and configure the certificate validation chain. The output is a test record for each factor type showing the replay attempt and the rejection.
Record the configuration baseline for assessors
Freeze the configuration in version control and export the settings that an assessor will examine: policy definitions, user resolver mappings, enrollment rules, token types allowed, replay tests and access path coverage. Keep logs of authentication events and administrative changes, since the audit controls in the same family depend on them. Map each artifact to the IA-2 determination statements in SP 800-53A Rev. 5, which describe the assessment procedures for each enhancement. The output is a configuration baseline package with a change log, which the system owner reviews and approves before the assessment begins.
Evidence assessors ask for under IA-2
This table lists the artifacts an assessor typically requests for IA-2 and its enhancements, which component produces each one, and what to confirm before the assessment. Use it to plan evidence collection early, since assessors decide whether any item is sufficient for the system and its authorization boundary.
| Artifact | What it shows | Produced by | Confirm before assessment |
|---|---|---|---|
| Identification and authentication policy and procedures | Which user populations must authenticate, how MFA applies to privileged and non-privileged accounts, and who approves exceptions | Client governance documents, mapped to IA-2 in the control implementation statement | Policy owner, review date and alignment with the organization-wide risk management process |
| Identity provider and MFA configuration exports | Authentication flows, required factors, token types and policy rules as configured in privacyIDEA, Keycloak or FreeIPA | privacyIDEA policy export, Keycloak realm export, FreeIPA configuration | Exports are taken from production, stored under change control and reviewed against the documented baseline |
| Enrollment records for each user and token | Which accounts have a registered second factor, token type, serial and enrollment date | privacyIDEA token list, Keycloak credential reports, FreeIPA OTP token records | Completeness against the directory, handling of unenrolled accounts and reconciliation with HR or joiner records |
| Enforcement settings per system | Proof that each in-scope system (VPN, Windows, Linux, SSH, web apps) actually requires the second factor | RADIUS, PAM, credential provider, SAML or OIDC client settings on each system | Test logins showing the factor is enforced, with no bypass path left open for privileged accounts |
| Audit logs of authentication events | Successful and failed logins, factor used, user, source and time, supporting unique user identification and review | privacyIDEA audit log, Keycloak event logs, FreeIPA and system logs forwarded to a SIEM | Log retention period, forwarding coverage, integrity protection and a documented review routine |
| Exception and group account approvals | Approved exceptions such as service accounts, shared or group accounts and break-glass accounts, with compensating controls | Client approval workflow, ticketing or identity governance records | Each exception has an owner, expiry, compensating control and a path to individual authentication where IA-2(5) applies |
| Replay resistance and phishing-resistant factor evidence | Which factors resist replay (IA-2(8)) and whether PIV or other accepted credentials are configured (IA-2(12)) | privacyIDEA token type settings, Keycloak WebAuthn configuration, PIV or x509 setup records | Whether the chosen factors meet the replay resistance requirement for each baseline the system uses |
| Mapping to SP 800-53A assessment procedures | Evidence for each determination statement and assessment method (examine, interview, test) for IA-2 and selected enhancements | Client compliance team, using the SP 800-53A procedures and the platform exports above | Assessors determine sufficiency. Confirm the objects they expect and the interview roles for each procedure |
What MFA tooling alone does not satisfy
IA-2 is an organizational control, so a working MFA server is only one part of meeting it. The cards below cover the policy, documentation and coverage gaps that assessors typically look for once the tool is deployed, and they explain why each one sits outside the software.
Policy, roles and ownership
IA-2 expects the organization to define how users are identified and authenticated, not only which product checks the password and token. Name a control owner, the teams that operate the MFA service, and the approvers for exceptions. Write down who enrolls tokens, who resets them and who reviews failed attempts. Without named owners, an assessor will find the control implemented in the server but unmanaged in practice.
System security plan entries
Each federal system needs a system security plan that states how IA-2 and its enhancements are implemented for that system. The entry should name the MFA service, the systems it protects, the token types accepted and the user populations covered. Keep it current when a new application is onboarded, because a plan that describes a different system than the one running will weaken every other piece of evidence.
Bypass routes around the second factor
MFA on the main login page does not cover legacy protocols, direct LDAP binds, API tokens, mail clients or a local console fallback that skips the RADIUS or PAM path. Inventory every authentication entry point for each system and test each one. Any route that accepts a password alone is an IA-2(1) or IA-2(2) gap, regardless of how well the primary flow is configured.
Group and service accounts
Shared administrator logins and service accounts often cannot answer a second-factor prompt, so teams disable MFA for them. IA-2(5) addresses individual authentication with group authentication in the high baseline. Document each shared or non-interactive account, its owner, the compensating control (such as vaulted credentials, key-based access or restricted source addresses) and the review cycle. Confirm with the assessor how these accounts will be evidenced.
Scope decisions and baseline selection
NIST does not choose the tool for you, and it does not estimate what compliance costs. The baseline selection (low, moderate or high) and any tailoring are decisions the organization makes under its own risk management process. Ask your authorizing official and assessor which enhancements apply to each system before buying hardware tokens or licenses, since the required scope changes the design and the effort.
Questions buyers ask about IA-2 and open source MFA
What drives the effort and cost of implementing IA-2 with open source MFA?
The main drivers are how many systems must enforce MFA, how many user stores and directories sit behind them, and how much of the estate has to be integrated one system at a time. Self-hosted privacyIDEA, Keycloak or FreeIPA carry no license fee for the core platform, but the work still has cost: servers and high availability, integration with each VPN, login path and web application, token enrollment and help desk support, and documentation for assessors. Ask any implementation partner for a quote built from a written scope that lists systems, user populations, token types and the evidence to be produced. No public benchmark in this page sets a figure, so compare quotes against that scope rather than against each other's totals.
How long does an IA-2 MFA rollout take, and what does the authorizing official decide?
Duration depends on scope, the number of integrations and how quickly the agency can approve changes, so ask for a written timeline tied to named milestones rather than a generic estimate. The authorizing official, the senior official who accepts the risk of operating a system, decides whether the MFA design and its evidence are sufficient for that system's authorization. Under FISMA, the agency's OMB Circular A-130 process sets how authorization fits into federal operations, and NIST does not set federal implementation timelines. Confirm early which system boundary the authorizing official will review, because MFA on a shared identity provider can affect several authorizations at once.
What must our team provide before an implementation partner can start?
The team has to supply the inventory that IA-2 work depends on. That includes the systems and applications in scope, the directories or user stores (such as LDAP or Active Directory), the list of privileged and non-privileged account populations, and the existing authentication flows. Security and compliance staff must confirm the control requirements for each system and the owner of each risk decision. Infrastructure staff must provide hosting, network paths, certificates and the change window. Assign a named owner for enrollment, recovery and help desk procedures, because assessors will ask how a user who loses a token is verified. Ask the partner to list these inputs in the written scope.
Can our internal team implement IA-2 MFA without an outside partner?
Yes, an internal team can implement it if it has engineers who can operate identity infrastructure and the time to maintain it. privacyIDEA supports installation with pip and on Ubuntu and CentOS or RHEL-family systems, and Keycloak documents production database, high availability and Operator options, so the technology is accessible. The harder work is consistent integration across VPNs, Windows and Linux logins, SSH and web apps, plus evidence collection and ongoing patching. Many agencies therefore split the work, keeping policy and ownership in-house while a partner handles the build, hardening and documentation. Decide which of those tasks your team can sustain after the project ends.
How do phishing-resistant factors like FIDO2 and PIV fit under IA-2?
IA-2 requires multi-factor authentication, but it does not require a specific factor type, so the choice of token is a design decision. IA-2(12) concerns accepting PIV credentials, which matters for agencies that already issue smartcards. privacyIDEA supports FIDO2 and WebAuthn passkeys, PIV and x509 smartcards, push, TOTP and HOTP, and Keycloak supports WebAuthn for its own logins. Phishing-resistant factors are generally the stronger choice for privileged accounts, but confirm how each token is enrolled, recovered and reported. Also confirm with the assessor and the agency's own policy which token types they accept for each baseline.
What do Inspectors General and assessors actually review for IA-2?
Assessors follow the SP 800-53A assessment procedures for IA-2, which combine determination statements with examine, interview and test methods. In practice they look at configuration exports showing which accounts require MFA, enrollment and recovery records, the list of exceptions with approvals, and logs showing authentication events. Inspectors General independently assess agency system security under FISMA and report results to OMB, so they review whether the controls operate as documented, not only whether they exist. Keep configuration baselines under change control, retain logs for the agency's required period, and test replay resistance and failure paths. DeployOpen prepares these systems, controls and evidence, but independent assessors and Inspectors General issue the conclusions.
Does open source MFA itself meet IA-2, or is the design what counts?
The software does not meet IA-2 by itself. IA-2 is satisfied by a system design and operating procedure that uniquely identifies organizational users, requires multi-factor authentication for privileged and non-privileged accounts, and resists replay where the baseline requires it. The platform is one component. Agencies must show how each system in the authorization boundary uses it, which accounts are excluded, and how exceptions are governed. NIST does not offer or endorse any compliance program or tool, so treat any claim that a product is 'IA-2 compliant' with caution and ask for the control-by-control mapping your assessor will use.
How DeployOpen scopes IA-2 MFA work and its evidence
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including self-hosted MFA for IA-2 work. We scope the written boundary of which organizational users, privileged and non-privileged accounts and systems fall under IA-2 before any build begins.
How we scope
- Confirm which systems, user populations and privileged accounts fall inside the IA-2 boundary of the system security plan
- Record which IA-2 enhancements your baseline selects and which system owners own each MFA requirement
- Agree in writing the scope, deliverables and timeline for fixed-scope engagements, with ongoing support available as a retainer
How we build
- Deploy self-hosted privacyIDEA, Keycloak or FreeIPA in your cloud accounts, data centers or air-gapped networks, aligned to the agreed IA-2 scope
- Connect each in-scope system through its supported integration point, such as the PAM module, RADIUS, SAML, OIDC or REST API
- Test replay resistance and MFA enforcement for privileged and non-privileged logins, and run security testing on the resulting access paths
How we hand over
- Document configuration, token enrollment and recovery procedures, and the mapping from each IA-2 requirement to the implemented control
- Deliver evidence packages such as configuration exports, authentication logs and test results for the assessor, prepared for independent auditors who issue any assessment outcome
- Train administrators and help desk staff on enrollment, lockout handling and change control for the MFA platform
How we support
- Maintain upgrades, backups and patches under a retainer, with operator update approval and version changes controlled by your team
- Re-test MFA coverage when new systems join the boundary or when the IA-2 baseline or your system changes
- Keep evidence current across assessment cycles so each review draws on configuration and log records that match production
