Why open source MFA for Linux servers and SSH is a different design problem
Second factors on Linux can be enforced centrally with FreeIPA OTP or the privacyIDEA PAM module, and the real decision is who owns the directory and the policy. Most Linux fleets were not built that way. Local accounts created during provisioning, shared administrative paths used during incidents, and service accounts that run cron jobs or deployment pipelines often sit outside any second factor, and nobody has a complete list of them. Start by inventorying every login path on every host: SSH with passwords or keys, console and recovery logins, sudo elevation, and the accounts automation uses to connect. Each one is a place where MFA can be missed.
Per-server setups drift because each host carries its own PAM stack, its own token files and its own exceptions. A change made to one host during an outage is rarely copied to the rest, and an auditor sampling random servers will find different answers. Central enforcement moves the policy to a shared identity store, with FreeIPA holding users, groups, host-based access rules and sudo rules, or with privacyIDEA resolving users from an existing LDAP or Active Directory source and applying token policies there. The PAM configuration on each host then becomes a thin, repeatable template that your configuration management tool can verify.
This scenario differs from the Windows logon and VPN pages in three ways. Linux administrators often reach hosts through keys and automation rather than interactive prompts, so MFA must be paired with an exception model for non-human accounts, usually handled through SSH certificates or tightly scoped service identities. Sudo elevation is a second decision point that needs its own rules. And the platform choice depends on whether your team already runs FreeIPA as the Linux identity source. Confirm which identity store your hosts already use before comparing products, because that choice determines whether the MFA server is a new system or an extension of an existing one.
Which requirements drive the SSH and sudo design
This table maps the HIPAA Security Rule and the FTC Safeguards Rule to concrete decisions for SSH and sudo on Linux fleets. Read each row as a requirement, the build decision it pushes toward, and the evidence to keep. Neither rule names SSH specifically, so confirm with your assessor how MFA applies to administrative access before you fix the design.
| Requirement | Build decision for SSH and sudo | Evidence to keep |
|---|---|---|
| Unique user identification (45 CFR 164.312, access control) | Give every administrator a named account from a central directory such as FreeIPA, and retire shared root logins and shared sudo accounts | Directory export of accounts, group membership and disabled leavers |
| Person or entity authentication (45 CFR 164.312) | Require a second factor for interactive SSH and for sudo elevation, so a stolen password alone does not grant a shell | PAM and SSH configuration from each host, plus MFA logs showing successful and failed attempts |
| Multi-factor authentication for any individual accessing an information system (16 CFR 314.4(c)) | Confirm with your assessor whether administrative SSH counts as access that must carry MFA, and cover every bastion and jump host first | Written scope of covered hosts and the rollout record for each host group |
| Audit controls and activity logs (45 CFR 164.312) and logging of authorized user activity (16 CFR 314.4(c)) | Forward sshd and sudo logs to a central SIEM and enable command logging for privileged sessions where your policy requires it | Log retention settings, sample sudo and login events, and an alert on failed MFA |
| Transmission security (45 CFR 164.312) | Use SSH with current key exchange and cipher settings, and keep privacyIDEA or FreeIPA OTP traffic encrypted between hosts and servers | SSH server configuration, TLS settings for MFA endpoints, and scan results |
| Service accounts and automation | Separate non-interactive accounts that cannot answer an MFA prompt, bind them to SSH certificates or keys with fixed commands, and record each owner | Inventory of service accounts, key or certificate owners and approval records |
| Break-glass and recovery access | Define an emergency account with tightly controlled credentials and a documented process to re-enroll tokens | Break-glass procedure, access logs for each use and periodic test results |
How FreeIPA OTP and the privacyIDEA PAM module each enforce a second factor
FreeIPA supports HOTP and TOTP tokens natively, so a Linux login can ask for a one-time code from the same directory that holds the accounts. Tokens are enrolled per user and can be software authenticators or hardware tokens such as YubiKeys. FreeIPA can also proxy OTP checks to an existing RADIUS server, which matters if a team already runs RADIUS for VPNs and wants one token store. The trade-off is scope: FreeIPA's OTP model covers one-time codes, so a team that needs push, FIDO2 or SSH key checks in the same flow should compare it against privacyIDEA before standardizing. Confirm which OTP options the chosen FreeIPA release exposes in its Linux PAM configuration, and confirm the RADIUS proxy behavior in a lab with your own token types.
privacyIDEA takes a different route: a PAM module sits in the Linux authentication stack and sends the check to a separate MFA service. That service handles TOTP, HOTP, push, FIDO2 and SSH keys, and can read users from an existing LDAP or Active Directory store through its user ID resolvers. For an administrator, the typical PAM-level experience is a password prompt followed by a second prompt for a code or an approval on a phone, and the SSH session opens only when both pass. The break points are non-interactive sessions: cron jobs, CI runners, backup agents and service accounts cannot answer a prompt, so they need an exception path such as a dedicated service identity with key-based access restricted by source host and command. Those exceptions must be documented and reviewed.
Before committing, build a lab that mirrors your SSH entry points, sudo rules and a sample of automation accounts, then test the exact PAM stack order on the Linux distribution and module versions you plan to run. Check what happens to sudo when the second factor is unavailable, whether the prompt appears on every connection or is cached, and how the stack behaves when the MFA service times out. Ask your implementation partner to show these results in writing, and confirm current module and release details with the FreeIPA and privacyIDEA documentation, since PAM behavior changes between versions.
Which platforms fit Linux MFA and why
Linux MFA usually comes down to where your user accounts already live and how SSH and sudo are authenticated today. The platforms below differ in whether they bring their own directory, which PAM path they support and how much of the login chain they cover. Use the cards to decide which combination matches your fleet before you write requirements.
FreeIPA for integrated Linux identity
FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients into one identity domain for Linux and UNIX hosts. It can issue HOTP and TOTP tokens, including YubiKeys, and host-based access control and sudo rules live in the same place. If your fleet already runs FreeIPA, MFA policy, enrollment and host access can be managed centrally rather than per server. Check that every host is enrolled as an IPA client, and that you can run two or more replicas per datacenter before depending on it for login.
privacyIDEA as the MFA layer
privacyIDEA is a self-hosted MFA platform that ships a PAM module for Linux, so SSH and console logins can require a second factor without moving the user directory. It supports TOTP, HOTP, push, FIDO2 and smartcards, and it can read users from LDAP or Active Directory. This fits fleets that run Active Directory, LDAP or a mix of stores and want MFA separate from the identity provider. Confirm the PAM module version and token types against your distributions, and test how sudo prompts behave with your automation before rollout.
Enterprise Edition support option
privacyIDEA is licensed under AGPLv3 and the project states that a privacyIDEA Enterprise Edition is available from NetKnights. Teams that need vendor-backed support terms or features outside the community build should price that option against the community deployment and the internal effort to run it. Ask NetKnights directly which features sit in each edition and what support levels are included, because the community license and the enterprise offer are not the same thing for a regulated buyer.
Keycloak for web SSO, not SSH
Keycloak is Apache-2.0 licensed and handles OpenID Connect, SAML and LDAP or Active Directory federation well, which makes it strong for web application SSO and MFA. It does not provide a native SSH or PAM login path on Linux hosts, so it does not cover the terminal logins this page is about. Use it for consoles, admin portals and web tools, and pair it with privacyIDEA or FreeIPA for SSH. Confirm any PAM or SSH integration on the current Keycloak release before assuming it covers host logins.
Keeping an existing directory as source
Many organizations keep Active Directory or another LDAP directory as the system of record and do not want to migrate users. privacyIDEA can read users from LDAP and Active Directory, so MFA can sit on top of the existing store. FreeIPA can also establish a cross-forest trust with Active Directory, but its IPA domain must use a DNS name that does not overlap with the AD forest. Decide early which directory owns usernames, groups and offboarding, because a disabled account must stop SSH access on every host.
Where SSH certificates fit alongside MFA
In this pattern, every interactive SSH session passes through a second factor at login, typically through the privacyIDEA PAM module or FreeIPA OTP, with keys or passwords as the first factor. No certificate layer sits between the user and the server, so the directory remains the single source of truth for who may log in. Revocation is immediate once the user is disabled or the token is removed in the central store, because the next login fails without any certificate expiring first.
- Revocation: disabling the account or token in the central directory blocks new logins at once, but sessions already open stay open until they end, so pair this with session termination procedures.
- Audit trail: each login attempt and MFA result can be logged centrally, which makes it easy to tie a session to a named user and a token.
- Who issues and rotates: the identity team issues tokens and enrolls users, while the platform team manages PAM configuration on each host.
- Operational load: users type a one-time code or approve a prompt for every session, which matters for scripted or frequent administrative access.
- Fit: this suits small fleets and interactive administrator access where per-session evidence matters more than convenience.
Before committing, confirm with your identity vendor which PAM stack and sudo behavior your Linux distributions support, and how the design behaves when the MFA service is unreachable.
In this pattern, a user first completes MFA against the central identity service, and the service then issues a short-lived SSH user certificate that the server trusts through its CA public key. Login uses the certificate rather than a standing key, so the server checks the certificate without calling the MFA service on every session. FreeIPA's integrated Dogtag certificate authority is one possible issuer, though other CAs can fill the same role. The lifetime, principals and issuance rules are a separate design decision that should be confirmed with your security team before rollout.
- Revocation: revocation depends on certificate lifetime and any revocation list the servers consult, so a short lifetime limits exposure but does not replace removing the user from the directory.
- Audit trail: the certificate identifies the principal and key ID, and the issuance log records the MFA event, so the two logs must be correlated.
- Who issues and rotates: the identity or PKI team operates the CA and signing process, and the platform team rolls out the trusted CA key to hosts.
- Operational load: users authenticate with MFA when requesting a certificate, then work normally until it expires, which reduces prompts for repeated sessions.
- Dependency: the CA becomes a critical service, and its key protection, backup and high availability need the same scrutiny as the MFA server.
Confirm certificate lifetimes, principal mapping, and the CA backup and key storage model with your PKI owner before design sign-off.
Automation such as CI pipelines, configuration management and scheduled jobs cannot answer an MFA prompt, so it needs a non-interactive credential that is still tightly bounded. Short-lived certificates issued to a workload identity can meet that need, provided the issuance path itself is controlled. This pattern keeps service accounts out of the MFA flow while avoiding long-lived private keys stored on build runners or in scripts. Its security depends on how the workload proves its identity to the issuer, which is a separate decision from the certificate lifetime.
- Revocation: very short lifetimes reduce the window after a compromise, but a compromised workload identity can request new certificates until its issuance rights are removed.
- Audit trail: log the workload identity, requested principals and issuance time, and map each job to a named owner so that automated access is attributable.
- Who issues and rotates: the platform or security automation team usually owns issuance rules, and rotation happens automatically rather than through people.
- Scope control: restrict each certificate to specific principals and hosts, and avoid a shared automation principal that can reach the whole fleet.
- Fit: this suits recurring jobs and deployment tooling, while human administrators should stay on the MFA-backed path.
Confirm with your security team the maximum certificate lifetime, how workloads authenticate to the issuer, and whether any automation still needs a break-glass credential that is separately monitored.
How to roll out SSH and sudo MFA without locking out administrators
The sequence moves SSH and sudo to a second factor in stages, with each phase producing an inventory, a tested recovery path or an enforcement record, so administrators keep working throughout the change.
Inventory hosts, local accounts and automation
The Linux team lists every host in scope, every SSH login path and sudo rule, and every local account, including break-glass and root-equivalent accounts. Automation is part of this list: CI runners, backup jobs, configuration management and monitoring agents that log in with keys or service accounts. The output is a register that marks each path as human interactive, human scripted or non-interactive, with an owner for each. The step is done when the register is reviewed by the platform owner and the security lead, and every non-interactive path has a named owner who has confirmed whether it can change.
Design the directory and token model
The team decides whether FreeIPA or an existing directory holds the users and groups, and whether privacyIDEA or FreeIPA's OTP support verifies the second factor. Hosts enrolled in FreeIPA use SSSD, while privacyIDEA's PAM module can be placed on hosts outside a FreeIPA realm. The design also sets which token types are allowed for administrators, how tokens are issued and how lost tokens are replaced. The output is a written design that names the user store, the MFA server, the PAM or SSSD configuration for each host class and the enrollment method. It is done when the security lead signs off and the design lists the gaps that remain for hosts that cannot be enrolled.
Build the FreeIPA topology before any enforcement
If FreeIPA is the identity source, the deployment recommendations call for at least two to three replicas in each datacenter, dedicated servers without other applications, and at least one replica per datacenter running PKI or DNS when those services are used. Each client should list at least two DNS servers. The team checks the replication topology and confirms that no replica exceeds four replication agreements. The output is a tested topology with documented replica roles. It is done when a user can authenticate against each replica, and replication status is monitored from a system that is not itself an IdM server.
Run a lab pilot on non-production hosts
A small set of non-production hosts receives the same PAM and sshd configuration planned for production. The pilot tests interactive login, sudo elevation, scripted logins from the automation inventory and what happens when the MFA server or a replica is unreachable. Each failure is logged and fixed in the configuration, not worked around manually on the host. The output is a pilot report listing each test, its result and the configuration change it required. It is done when the same test set passes twice on consecutive configuration builds.
Establish break-glass accounts and test recovery
Before any production enforcement, the team defines break-glass access for the case where the MFA path fails. This includes a documented emergency account or procedure, stored under dual control, and a rule for when it may be used and who must be notified. Recovery is exercised, not only written down: a backup is restored into a separate lab topology and an administrator logs in with the recovery path. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restores are tested in isolation. The output is a recovery runbook and a dated record of the successful restore test. It is done when the platform owner has observed the recovery path work from a clean starting point.
Enforce MFA for administrators and sudo first
Enforcement starts with the accounts that have the most access: administrators with sudo rights and the accounts that reach production hosts. The team enables the second factor for those groups on a limited set of hosts and widens the scope in steps, watching authentication failures and help desk tickets after each change. Sudo elevation is included in the same phase so that an administrator who logs in with a key still needs a second factor before running privileged commands. The output is an enforcement log per host group with the date, the change and the observed failure rate. It is done when the enforced groups log in successfully for a full operating cycle without help desk escalations that point to the configuration.
Remove shared and bypass access paths
Once enforcement is stable, the team removes the paths the register flagged: shared accounts, direct root logins, keys with no owner and password-only fallbacks that were kept for convenience. Where a non-interactive job still needs access, the team moves it to a dedicated service identity with a narrow command scope, or to a certificate-based path if the design allows it. The output is a closed register with each path either removed, moved or accepted with a documented owner and reason. It is done when a configuration review of sshd, PAM and sudoers on the in-scope hosts matches the design, and the auditors have been shown the evidence for each removed path.
Confirm the audit trail and hand over operations
The last phase checks that authentication events from sshd, PAM and sudo reach the log platform with enough detail to show who authenticated, with which factor and from which host. The team confirms that the break-glass path and any change to MFA policy are logged and reviewed. Operating tasks, including token replacement, replica health checks and backup restores, are assigned to named owners in a runbook. The output is the operations handover pack and a list of the evidence the compliance team will request. It is done when the platform owner and the security lead accept the handover in writing.
What evidence the auditor will ask for from SSH MFA
What enrollment records will an auditor ask for per administrator?
The auditor will ask for a record showing which administrator enrolled which second factor, when, and who approved it. Keep one entry per named account, listing the token type (TOTP, HOTP, hardware key or smartcard), the enrollment date, the enrolling operator and any revocation or replacement. In a FreeIPA deployment, OTP token records sit in the directory and can be exported per user. In privacyIDEA, token enrollment and assignment events are logged, and the token inventory can be exported. Confirm with your auditor whether they want the enrollment approval step documented as a separate ticket or within the identity system's own history.
Which PAM and sudo configuration should be exported from the fleet?
Export the effective PAM stack and sudoers rules from every managed host, not only the templates. The evidence should show that the SSH daemon and sudo require the privacyIDEA PAM module or FreeIPA OTP authentication, and that no host carries a local bypass. Capture the configuration files, such as those under /etc/pam.d/ and /etc/sudoers.d/, along with the SSH daemon settings in sshd_config, with a timestamp and host identifier. Configuration management output, such as a dated report from your tooling, is usually easier to defend than a manual screenshot. Ask the auditor how often they expect the export to be repeated during the review period.
What authentication logs prove each login used a unique identity?
The logs must tie every SSH and sudo session to one named person, with the second factor result recorded. Forward authentication events from the PAM module, the SSH daemon and sudo to a central store, so that the log shows the user, host, source address, time and whether MFA succeeded. Wazuh can collect and retain these events from Linux hosts, and privacyIDEA records its own validation decisions. Shared or generic accounts break this chain, so the auditor will check that no interactive login uses a shared identity. Confirm the retention period with your compliance lead before the review period starts.
How should changes to MFA and access policies be documented?
Show a change history for every policy that governs SSH and sudo, including who changed it, when, why, and who approved it. Versioned policy files in a Git repository with reviewed merge requests provide this trail for configuration. For FreeIPA host-based access control and sudo rules, the directory keeps its own modification records, which you should export alongside your repository history. Compare the two sources at each review to confirm that what was approved is what runs on the hosts. Changes made outside the approved path are a finding in their own right, so record emergency changes with the ticket that followed them.
How is the exception register for service accounts kept?
Service accounts and automation that cannot answer a second factor need a documented exception, an owner and a compensating control. The register should list each account, the hosts it reaches, the reason MFA is not possible, the compensating control (such as key restriction, source address limits or certificate lifetime), the review date and the approver. Automation that uses SSH certificates should record the certificate authority, validity period and principal list. Auditors often test the register against the live account inventory, so the two must match. Confirm with your assessor which compensating controls they accept before you rely on them.
Which component produces each piece of SSH MFA evidence?
Each evidence item comes from a different place, and the auditor will expect a clear mapping:
- Enrollment and token inventory: FreeIPA or privacyIDEA
- PAM and sudo configuration: configuration management records and the hosts themselves
- Authentication and sudo events: SSH and sudo logs forwarded to a SIEM such as Wazuh
- Policy changes: version control and the identity system's modification history
- Exceptions: the register, reconciled against the account inventory
Build a one-page map that names the system, the owner and the retention for each row before the assessment starts.
Can DeployOpen provide the audit report for our SSH MFA controls?
No. DeployOpen prepares the systems, controls and evidence that an assessment needs, including exports, log forwarding, documentation and the exception register structure. Audit reports, attestations and certifications are issued only by independent auditors or certification bodies. In a fixed-scope engagement, the evidence deliverables are listed in the written scope so you know what is produced before work starts. Your auditor decides what is sufficient, so involve them in agreeing the evidence list early.
What to ask an implementation partner about Linux MFA
Start with the directory design, because everything else depends on it. Ask the partner how many FreeIPA replicas they propose in each datacenter, how replication agreements are limited per replica, and where the PKI and DNS roles sit. The FreeIPA deployment recommendations call for at least two to three replicas per datacenter and dedicated servers, and they advise at least two DNS servers in each client's resolv.conf. Ask who will confirm name resolution and time sync for every fleet segment before any PAM change is pushed, and whether a failed replica can still serve OTP checks to the hosts that depend on it.
Ask how the PAM stack is tested before it reaches production. Each distribution in the fleet should have its own test matrix covering /etc/pam.d/sshd, sudo, console and recovery logins, with the SSSD and privacyIDEA PAM module versions pinned and recorded. Require a test plan that proves a locked-out administrator can still reach a host through the break-glass path, and a written rollback plan that restores the previous PAM configuration through configuration management. Confirm in writing how the partner will handle a host that fails the MFA prompt during a patch cycle.
Service accounts and automation need an explicit decision, not a default. Ask which non-interactive accounts, CI runners and backup jobs will be exempted, how each exemption is tied to a named owner and a key-based or certificate-based control, and how exemptions are reviewed. Ask for the break-glass procedure in writing: who holds the emergency credentials, where they are stored, who approves their use, and how each use is logged and reported. Finally, ask how audit records from SSH and sudo reach the SIEM, which log fields are normalized, and who tests that an MFA failure produces an alert. Confirm that the scope, deliverables and timeline are fixed and agreed in writing before any change window is booked.
How much does open source SSH MFA cost and how long does it take?
What drives the total cost of open source MFA for SSH?
The main cost drivers are the number of host classes, the servers that run the directory and MFA services, the token hardware you buy, and the labor to integrate and test each host class. Software licenses are not the main line item because FreeIPA is GPL-3.0-or-later with no paid edition of its own, and privacyIDEA is licensed under AGPLv3. Costs fall into one-time work (design, integration, service account remediation, testing, documentation) and recurring work (servers, patching, backups, token replacement, support). Ask any partner for a written quote that separates these, lists the host classes in scope, and states which high availability design is assumed, including the number of replicas per datacenter.
Can a small IT team set up SSH MFA on its own?
It depends on two things: directory skills and fleet diversity. A team that already runs LDAP, Kerberos or a similar directory and understands PAM and sudo can often handle a single fleet with uniform images. A team without that background will spend most of its effort learning replication, certificate handling and sudo rule design, which is where mistakes lock people out. Fleets with mixed distributions, legacy appliances, or many service accounts take longer regardless of team size. Before deciding, ask who on the team will own the directory after go-live, since FreeIPA deployments need at least two to three replicas per datacenter and dedicated servers.
How long does it take to get the first enforced SSH login with MFA?
The honest answer is that the timeline depends on your fleet inventory, not on a fixed figure. The first enforced login can only be scheduled after you know which hosts use local accounts, which use a central directory, which run sudo rules by hand, and which services or scripts log in with passwords or keys. A small, uniform pilot group can move quickly once the directory and token enrollment are working. Full fleet coverage takes longer because each host class needs its own PAM test, rollback path and change window. Ask any partner to base the schedule on a written inventory and to name the pilot group and rollback steps in the scope.
What does the work need from our team before it starts?
The work needs named owners and access, not only budget. Typically you need directory owners who can approve schema, group and sudo rule changes, a change manager who can book maintenance windows, and administrators who can grant root or sudo access to the hosts being changed. You also need someone who owns the service account list, because automation and batch jobs usually cannot prompt for a second factor and must be moved to keys, certificates or a documented exception. Confirm these owners in the written scope, along with who signs off on each host class before enforcement.
Is FreeIPA or privacyIDEA cheaper to run for SSH MFA?
Neither is cheaper by default, because the license costs are not the deciding factor. FreeIPA bundles the directory, Kerberos, certificate authority and sudo and SSH policy in one system, so it can reduce the number of components you operate if you do not already have an identity platform. privacyIDEA adds the PAM module and token management on top of an existing user store such as LDAP or Active Directory, which suits organizations that want to keep their directory. Run-cost differences come from the directory you already have, the number of servers, and the skills your team has. Ask partners to price both designs in the same quote, using the same host classes and high availability model.
Does SSH MFA cost more if we already use SSH certificates?
Certificates change the design more than the price. SSH certificates can handle trust for many hosts without distributing individual keys, but they still need an issuing process and a decision about when a second factor is required at signing time. Some teams keep MFA on interactive logins and use certificates for automation, while others require a second factor when a short-lived certificate is issued. The extra work is in the issuing policy, key lifetimes and audit trail rather than in additional licenses. Ask any partner how certificate issuance will be authorized and logged, and whether this is priced as separate scope.
What should a written quote for SSH MFA include?
A useful quote lists the host classes in scope, the directory design, the high availability model, and the token types with their quantities and replacement plan. It should also separate one-time integration, service account remediation, testing and documentation from recurring hosting, patching, backups and support. Ask for the assumptions behind the schedule, the pilot group, the rollback procedure and the acceptance criteria for each host class. DeployOpen works on fixed-scope engagements agreed in writing before work starts, and does not publish a price list, so the quote follows from the written scope.
How DeployOpen scopes and supports Linux MFA
DeployOpen plans, implements, hardens, documents and supports self-hosted MFA for Linux and SSH inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. For this path, a typical scope covers the identity store (for example FreeIPA or an existing LDAP directory), the privacyIDEA PAM module on the target fleet, the token enrollment process, the break-glass procedure for locked-out administrators, and the sudo policy that decides which commands require a second factor. Most engagements are fixed-scope, so the list of hosts, the account classes in scope, the token types and the rollout order are agreed in writing before any work starts. Ongoing patching, upgrades and monitoring are available as retainers.
Security testing of the SSH path is a separate, optional workstream. It can check whether the second factor actually runs for interactive logins, whether sudo and su honor the policy, whether password-only fallback is closed on hosts that should not allow it, and whether service accounts are kept out of the interactive MFA path without becoming a backdoor. DeployOpen prepares the configuration evidence an assessor will ask for, such as policy exports, enrollment records, authentication logs and change history for the PAM and SSH settings. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, and you should agree with your assessor up front which artifacts they will accept.
DeployOpen does not publish a price list. A quote follows from the written scope, so ask each provider to itemize the cost of server build and high availability, PAM module packaging across distributions, host onboarding, token procurement, help desk support during cutover, documentation and any testing. Confirm who owns the configuration after handover, which changes are included in a retainer, and how emergency access is handled if the MFA service is unreachable during an incident.
