Open source MFA for VPN and RADIUS: why remote access is the first place to start
Remote access is usually the first place to add a second factor because a VPN concentrator or firewall that accepts only a password is the easiest path into the network for an attacker holding stolen credentials. Remote staff and vendors reach internal systems through that gateway, and a regulator or auditor who asks how remote network access is protected will expect MFA there. Self-hosted open source MFA can sit in front of OpenVPN, Fortinet and Palo Alto gateways without replacing them, as long as the gateway can send the authentication request to a RADIUS server that performs the second-factor check.
RADIUS is the common bridge because these gateways already speak it, so the second factor can be added on the authentication server rather than rebuilt in each product. For most teams the short answer is privacyIDEA when token breadth matters, since it supports RADIUS for VPNs alongside hardware keys, smartcards, push and TOTP. FreeIPA is the better fit when the user store is already Kerberos and LDAP and the team wants identity, OTP and certificates in one directory, with the caveat that its OTP options are narrower. Confirm with each gateway vendor which RADIUS features, challenge-response modes and push flows its current firmware supports before choosing.
The FTC Safeguards Rule (16 CFR 314.4) requires covered financial institutions to implement MFA for anyone accessing an information system, and the HIPAA Security Rule (45 CFR 164.312) requires unique user identification, audit controls and person or entity authentication for systems that hold ePHI. Neither rule dictates a product or a specific MFA method, so the evidence matters as much as the tool. Plan to keep RADIUS server logs, gateway authentication logs, enrollment records and failover test results that show which accounts were covered and when. Confirm with your own assessor which of these records they will test.
Which requirements shape the VPN MFA design
This table maps the FTC Safeguards Rule MFA and logging requirements and the HIPAA access control and audit controls to concrete VPN build decisions. Read each row as a design question, and confirm with counsel or your compliance lead which rule applies to your organization before you rely on it.
| Requirement | Build decision for VPN MFA | Evidence to keep |
|---|---|---|
| FTC Safeguards Rule MFA for any information system (16 CFR 314.4), if covered | Enforce the second factor on every VPN gateway, SSL portal and remote access path, not only the primary one. Inventory backup gateways and admin consoles too. | Gateway list with RADIUS MFA enabled, and exception records for any path without MFA |
| HIPAA unique user identification (45 CFR 164.312), if covered or a business associate | Map each person to one directory identity in FreeIPA or the LDAP store that privacyIDEA reads. Block shared VPN accounts and vendor logins under generic names. | User-to-identity mapping, enrollment records, and reports of shared or duplicate accounts |
| HIPAA person or entity authentication (45 CFR 164.312), if applicable | Set the RADIUS challenge flow so each login requires the password plus the second factor. Confirm the gateway rejects sessions that skip the challenge. | Gateway test results for the challenge flow and configuration exports |
| HIPAA audit controls (45 CFR 164.312), if applicable | Send privacyIDEA authentication events and gateway session logs to a central store. Confirm which events each gateway can export before you design the pipeline. | Sample log extracts showing user, time, source, gateway and result for successful and failed logins |
| FTC monitoring and logging of authorized user activity (16 CFR 314.4), if covered | Set a retention period with your compliance lead, protect logs from tampering, and review failed MFA attempts on a fixed schedule. | Retention policy, access list for log stores, and review records |
| Continuity of remote access during an MFA outage | Run at least two RADIUS or privacyIDEA nodes, define a documented fallback policy, and test the failover path. Decide who can approve emergency bypass and how it is logged. | Failover test records, bypass approval procedure, and bypass logs reviewed after each use |
| Encryption of customer information in transit (16 CFR 314.4), if covered | Confirm RADIUS traffic between gateways and MFA servers is protected or isolated on a dedicated network segment, since standard RADIUS protection depends on configuration. Verify with your gateway vendor. | Network diagram, segment controls, and configuration evidence for shared secrets |
Which open source platform fits a RADIUS MFA front end
A RADIUS-based MFA front end for VPNs usually comes down to two questions: where the users already live, and which second factors the organization must accept. The cards below compare the candidates on those points, plus the web-portal option, and end with the checks to run before committing to one.
privacyIDEA as the RADIUS MFA server
privacyIDEA is built as an MFA server, so it fits VPNs that authenticate with RADIUS, including OpenVPN, Fortinet and Palo Alto. It reads users from existing stores through its user ID resolvers, covering LDAP and Active Directory, SQL, SCIM and HTTP sources, so the directory can stay where it is. Confirm that your specific VPN model accepts RADIUS challenge-response, because that behavior decides whether push and token prompts work at login.
Second factors offered by privacyIDEA
privacyIDEA supports push through its own authenticator app, TOTP and HOTP, FIDO2 and WebAuthn keys, and PIV or x509 smartcards. Standard TOTP and HOTP apps work without a custom client, but push requires the privacyIDEA Authenticator app. Decide early which factor each user group gets, since remote staff, contractors and admins often need different options and VPN prompts vary by vendor.
FreeIPA as the identity and OTP store
FreeIPA combines 389 Directory Server, MIT Kerberos and a Dogtag certificate authority, so it suits organizations that want one Linux and UNIX identity platform with OTP built in. It supports HOTP and TOTP tokens, including hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server, which lets it sit in front of a VPN. Check whether FreeIPA's OTP path covers the VPN models you run, because FreeIPA does not replace privacyIDEA's push and smartcard coverage.
FreeIPA licensing and support model
FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own. Cost therefore sits in the people and services around it: installation, replica design, support contracts and the work to integrate it with your VPN. Compare that with privacyIDEA, where the optional enterprise edition from NetKnights is a separate commercial decision. Ask any partner to separate license cost from implementation and support cost in writing.
Keycloak for web-based VPN portals
Keycloak fits when the VPN is reached through a web portal or the vendor supports SAML or OpenID Connect sign-in. It is not a RADIUS server, so it cannot replace a RADIUS front end for clients that only speak RADIUS. Use it for SSO into the portal and confirm the VPN vendor's SAML or OIDC support before design. If the portal uses RADIUS behind it, the MFA decision still sits with the RADIUS layer.
Confirm RADIUS support before choosing
Verify each candidate against your own VPN models, not against general claims. Check the RADIUS dialect and attributes your devices send, timeout and retry behavior, challenge handling for push and OTP, and how the server behaves when a second server is configured for failover. Run a proof of concept with one test VPN gateway and a non-production user group before any production rollout.
How a VPN login with a second factor moves through RADIUS
This sequence shows how the gateway, the RADIUS server and the user store cooperate so that a remote login succeeds only after both the password and the second factor are verified, and what each hop records for audit.
User starts the VPN connection
The remote user opens the VPN client and submits a username and primary password to the VPN gateway, which is typically OpenVPN, Fortinet or Palo Alto. The gateway does not check the password itself when it is configured for RADIUS authentication. It holds the request open until a RADIUS answer arrives. You know this step is working when the gateway shows a pending authentication rather than an immediate local rejection, and when its own log records the session attempt with the source address and username.
Gateway sends an Access-Request
The gateway builds a RADIUS Access-Request packet containing the username and the password it received, and sends it to the configured primary and secondary RADIUS servers, which in a resilient design are separate hosts. The gateway needs a shared secret for each RADIUS server and a source address the server accepts. Confirm with your gateway vendor how it orders the servers, how long it waits before failing over, and whether it can send the second factor in the same request or must prompt for it in a second round. The gateway log records the request, the target server and any timeout.
RADIUS server checks the primary password
The RADIUS server, such as privacyIDEA or a FreeIPA-backed setup that proxies to RADIUS, resolves the username against the user store, which can be LDAP or Active Directory, a SQL table or a local file. It verifies the primary password against that store. If the password is wrong or the account is locked or disabled, the server returns Access-Reject and the sequence ends here. The server log records the user, the resolver used and the outcome, without the password itself.
RADIUS server issues the OTP or push challenge
When the password is correct, the RADIUS server looks up the token assigned to the user and sends an Access-Challenge back to the gateway with a prompt, such as a request for a one-time code or a notice that a push has been sent. For push, the server contacts the phone app and waits for the user to approve. For OTP, the server holds the challenge state so the code can be matched to this attempt. You know the challenge is in place when the gateway displays the prompt and the server log shows a challenge event tied to the same session state.
User returns the second factor
The user enters the one-time code or approves the push on the registered device. The gateway forwards this response as a second Access-Request that carries the state value from the challenge. The RADIUS server validates the code against the token's counter or time window, or confirms the push response, and rejects reuse of a code that was already accepted. A failed attempt is logged with the token serial and the reason, which gives the audit trail for repeated failures and lockouts.
RADIUS returns Access-Accept or Access-Reject
If both factors pass, the RADIUS server returns Access-Accept, optionally with attributes such as group membership or session policy that the gateway uses to assign the right network profile. If either factor fails, it returns Access-Reject. The gateway then either opens the tunnel or closes the attempt. You know the design is correct when an accepted login shows entries on both the RADIUS server and the gateway, with matching usernames and timestamps.
Log events for the audit trail
Each hop writes its own record: the gateway logs the session and tunnel state, and the RADIUS server logs the password check, the challenge, the second-factor result and the token used. Ask your implementation partner to forward both sets of logs to your central log store, and confirm the retention period your regulator or internal policy requires. Test the path by running a deliberate failed login and confirming that the same event appears in both places, so an examiner can reconstruct any single session.
Push, OTP or hardware key: choosing the second factor per VPN user group
Employees on company laptops usually have the most options. Push notifications give the smoothest experience, but they need the privacyIDEA Authenticator app installed on a phone that the user keeps with them. Staff who refuse or cannot install that app can keep standard TOTP or HOTP tokens in apps such as Google Authenticator, which privacyIDEA supports as ordinary OATH tokens. Enrollment is the main workload here, so plan self-service enrollment and a help desk path for lost phones.
- Push with the privacyIDEA Authenticator app: Fastest approval for users with a company or personal smartphone, and the user confirms on the device.
- Standard TOTP or HOTP apps: Users who will not install a push app can keep an authenticator app they already use.
- Hardware tokens for exceptions: Issue OTP hardware tokens to staff who have no phone or who work in locations where phones are restricted.
- Enrollment policy: Decide who enrolls which token type and whether self-service is allowed.
- Fallback for lost devices: Define how a user re-enrolls without weakening the login.
Confirm with your staff population which devices they carry and whether your policy allows personal phones for work apps.
External users often cannot be given company phones, and some work from shared or unmanaged machines. Push may still work if the contractor uses their own phone, but many vendor policies forbid installing extra apps. Standard TOTP or HOTP tokens in a third-party app are common for this group, and hardware OTP tokens suit contractors who must not hold a phone. Expiry is important, because accounts for vendors should end when the contract does.
- Time-limited accounts: Tie token validity and VPN access to the contract end date so accounts do not outlive the engagement.
- Token type by contract: Use TOTP or HOTP apps for most vendors and hardware OTP tokens where a phone is not allowed.
- Shipping and logistics: Hardware tokens need a process for shipping, activation and return, which the implementation partner should plan with you.
- Shared-device risk: Confirm whether vendors use managed or unmanaged computers, since this affects how much you rely on the second factor alone.
- Support boundaries: Decide whether the vendor's own staff or your help desk resets tokens.
Confirm the contract terms and whether vendor staff may carry personal phones before you choose the token type for each vendor.
Administrators who connect to the VPN to reach servers, network devices or firewalls usually warrant the strictest second factor. Hardware tokens and FIDO2 security keys are the natural fit, because they keep the factor on a dedicated device. Keep separate administrator accounts for VPN access if possible, so that a compromised everyday account does not grant administrative reach. Push and OTP apps remain possible, but they run on the same phone many administrators use for everyday communication.
- Hardware OTP tokens: Use hardware tokens that privacyIDEA can import or enroll, kept separate from the admin's personal devices.
- FIDO2 and passkey keys: privacyIDEA supports FIDO2 and WebAuthn hardware keys, which can be considered for this group.
- Separate admin accounts: Give administrators a dedicated VPN identity with its own policy.
- Lockout and recovery: Keep a documented, tested recovery path that does not depend on the admin's only token.
- Logging: Make sure each administrator's VPN logins appear in your audit trail.
Confirm which admin accounts reach which networks and whether your VPN appliance can enforce separate policies for them.
Across all groups, the choice has two limits that matter. Push notifications and SMS depend on the phone having a working data or cellular connection and on a provider path to reach it, so a user in a dead zone or on a restricted network may be unable to approve. TOTP and HOTP codes and hardware tokens work without a network connection on the device, which makes them more reliable in those conditions. Phishing resistance is a separate question: OTP codes and push approvals can be phished, and that topic is covered in its own page.
- Connectivity dependency: Push and SMS need the phone to reach its network and the notification service, while OTP codes do not.
- Offline use: Test whether each token type works in the locations your staff actually use.
- Mixed policies: Allow more than one token type per user so a failed device does not block access.
- Phishing resistance: OTP and push codes can be relayed by attackers, so do not treat them as phishing-resistant controls.
- Vendor confirmation: Confirm with the privacyIDEA project or your partner which offline and push behaviors apply to your version.
Before you choose, test each token type from the locations and devices your users will actually use.
Designing failover so a RADIUS outage does not lock out remote staff
The first design decision is what must keep working when the MFA path fails, because a RADIUS outage can fail in four different places and each one needs its own answer. A single RADIUS node can go down, the network path between the VPN gateway and the RADIUS service can break while both ends are healthy, the user store that privacyIDEA reads through its user ID resolvers (LDAP, Active Directory or SQL) can become unreachable, or the token store can be corrupted or fall out of sync. A design that only covers the first case will still lock out staff in the other three. Map each failure to the component that owns it, then decide what the gateway does in each case.
Redundancy starts with at least two RADIUS endpoints behind the gateway, placed so that a single site, rack or network segment cannot take out both. Confirm with your gateway vendor whether the device accepts a list of secondary RADIUS servers, how it decides a primary is dead (repeated timeouts, a failed probe or a refused connection), and whether it returns to the primary automatically after recovery. Test each of these by stopping a node and watching the gateway, not by reading the configuration. Also confirm that the RADIUS secret, client definitions and attribute mappings are identical on every node, since a mismatch on the standby often surfaces only during a real outage.
The hardest choice is whether to fail open or fail closed for named groups. Failing closed keeps the second factor strict but means a broken MFA path blocks every remote user in scope, including the administrators who would fix it. Failing open lets users in on password alone during the outage, which is a real weakening of the control and may conflict with what your regulator or auditor expects for remote access. A common middle path is to fail open only for a small, named break-glass group with strong credentials, separate logging and alerting on every use, and a time limit on the exception. Record the decision, the owner who approves it and the test that proves it works. Confirm the exact behavior with your gateway vendor and your privacyIDEA deployment before the policy is written.
Rolling out VPN MFA in phases without a single cutover day
A staged sequence lets remote access gain a second factor gateway by gateway, with a tested fallback at every step so that a RADIUS problem never locks out the whole remote workforce. Each phase closes with a written artifact that the security and network teams can review before the next one starts.
Inventory gateways and current authentication paths
List every VPN concentrator, firewall gateway and portal that handles remote access, and record how each one authenticates users today, whether through local accounts, an existing RADIUS server, LDAP or SAML. Note which gateways accept shared service accounts, which groups of staff use each one, and which vendors or contractors depend on them. The output is a gateway inventory signed off by network and security owners, with each gateway marked as a pilot candidate, a later wave or an exception.
Stand up the MFA service and fallback path
Install privacyIDEA or configure FreeIPA as the RADIUS-facing second factor, with the high availability design, backups and monitoring agreed in the previous phase. Keep the existing authentication path intact so that the gateway can still fall back to it if the new service is unreachable. The output is a test environment that passes a documented failover check, where the gateway is deliberately pointed at a dead RADIUS server and the team confirms that login behaves as the runbook says.
Pilot with a test group and a single gateway
Enroll a small group of IT and security staff on one non-critical gateway, and enable RADIUS challenge handling for them only. Test push, OTP and any hardware token types you plan to support, plus the user experience on the VPN client, from both managed and unmanaged devices. Record every failed login and support call during the pilot. The output is a pilot report listing token types tested, failure causes found and changes made to the configuration.
Migrate the user store and enroll tokens
Connect the MFA service to the directory that holds your remote users, using an LDAP or AD resolver, and confirm that group membership maps to the policies you intend to apply. Where an existing hardware token inventory exists, import seed files only through the documented import formats and verify each serial against the directory. Enroll remaining users through a controlled process with identity checks at the help desk. The output is an enrollment report by group showing enrolled, pending and unenrolled users, plus a reconciled list of any tokens that failed import.
Enable MFA on the first production gateway
Switch the first production gateway to require the second factor for the enrolled groups, with the fallback runbook printed and tested in the same change window. Watch authentication logs for RADIUS timeouts, rejected challenges and lockouts through the first full working days of use. Keep the exception path defined in advance so that a locked-out user can be supported without disabling MFA for everyone. The output is a tested failover runbook and a short log review confirming that the gateway behaves as the pilot predicted.
Expand gateway by gateway and group by group
Add the remaining gateways and user groups in waves, starting with lower-risk populations and moving to administrators, contractors and vendor accounts last. Before each wave, confirm that the enrollment rate and help desk capacity match the population being added. Document each exception with an owner and an end date agreed with the business. The output is a signed-off exception list for every group that cannot yet use MFA, with a review date for each entry.
Retire the fallback and keep the evidence
Once every in-scope gateway enforces MFA and the exception list is accepted, remove the single-factor fallback and disable local accounts that can bypass the second factor. Keep the failover runbook and test it on a schedule agreed with operations, so that the fallback still works if the MFA service fails. Store configuration exports, enrollment reports and authentication logs in the audit repository your assessors will ask for. The output is a closing configuration baseline and evidence package that auditors can trace from policy to gateway setting to log.
Evidence auditors ask for from VPN MFA logs
This table lists the evidence an examiner typically requests for second-factor access to VPNs, the component that produces each item, and what the reviewer will check in it. Read it as a pre-assessment checklist: if a row has no owner or no retained artifact, expect questions during fieldwork. The main takeaway is that the RADIUS server and the gateway each hold part of the story, so both need to be exported and retained.
| Evidence item | Produced by | What the reviewer checks |
|---|---|---|
| Gateway configuration exports | VPN gateway (OpenVPN, Fortinet, Palo Alto or other) | That every remote access profile points to the RADIUS MFA server and that no profile allows password-only login |
| RADIUS client definitions | privacyIDEA or FreeIPA RADIUS configuration, plus gateway RADIUS settings | That each gateway is registered as a client with an approved shared secret and that no unlisted client can reach the server |
| Enrolled second-factor user list | privacyIDEA token database or FreeIPA OTP records, reconciled to the user directory | That every remote user has an active token, that tokens are tied to a named person and that disabled or leaver accounts have no active token |
| Authentication logs with success and failure | privacyIDEA audit log, FreeIPA and KDC logs, and VPN gateway logs | Timestamped successful and failed MFA attempts with user, source address and token type, retained for the period the policy sets |
| Log forwarding and retention settings | Central log pipeline or SIEM receiving RADIUS and gateway logs | That logs leave the MFA server and gateway, that retention matches policy and that log integrity is protected |
| Failover test records | Operator runbook results, with the test plan, dates and outcomes | Proof that a secondary RADIUS server or documented fallback works when the primary is stopped, and what remote staff experienced |
| Exception and change records | Ticketing system and change approvals for bypasses, token resets and gateway changes | Named approver, business reason, expiry date for each exception and a link to the configuration change that followed |
Questions to ask an implementation partner about VPN MFA
Start with the gateway model. Ask the partner which VPN gateways, firmware versions and RADIUS features are in scope, and whether each one has been tested against privacyIDEA or FreeIPA in a configuration close to yours. Gateways differ in how they handle Access-Challenge responses, which is what push and OTP prompts rely on, and in whether they accept a second RADIUS server for failover. Ask for the vendor documentation the partner used for each gateway, and confirm the firmware baseline in writing. Do not accept "RADIUS is supported" as an answer. Ask the partner to name the gateway settings it will change and which of them need a change window.
Ask who tests failover, how, and who signs off. The partner should describe a test in which the primary RADIUS server is stopped, the gateway falls back to the secondary, and a remote user can still connect under the approved fallback policy. Ask whether your security team, the network team or the partner runs that test, and whether the result is recorded as evidence. Also ask how exceptions and break-glass accounts are approved, who holds the credentials, how their use is logged and how they are reviewed and retired. Request the written approval workflow before any build begins, since the scope should state these decisions explicitly.
Ask how authentication events from the RADIUS and privacyIDEA layer reach your SIEM, which fields are forwarded and how time sync is confirmed across the gateway and MFA servers. For token import and enrollment, ask which token formats the partner will import (for example, OATH CSV or Yubikey CSV seed files), how seed files are transferred and destroyed, and how enrollment will run for the full user population, including the help desk workload. Finally, agree the handover list in advance: configuration exports, runbooks, test results and the access matrix. Ask for the written, fixed scope, deliverables and timeline before work starts, because DeployOpen engagements are scoped in writing.
How much work is open source VPN MFA, and what drives the cost?
What drives the cost of adding MFA to a VPN with RADIUS?
The main drivers are the number of gateways, the number of user stores, the token types you enable and the failover design. Each gateway needs its RADIUS client configured and tested, so a single Fortinet or Palo Alto appliance is a small task while a mixed estate of OpenVPN, vendor appliances and legacy concentrators multiplies the testing. Each user store, such as an LDAP directory or a FreeIPA domain, adds resolver configuration and attribute mapping. Token types matter because push, TOTP, hardware keys and smartcards each need enrollment flows, help desk steps and user guidance. A failover design with a second RADIUS path adds build and test work that a single-server pilot does not need. The MFA cost page sets out the full cost model, and a written scope should list each gateway, store and token type separately.
How long does a pilot of open source VPN MFA usually take?
A pilot's length depends on how many gateways it covers, how quickly the client can grant access to the user store, and whether the approval chain is clear before work starts. A pilot with one VPN gateway, one directory and one token type is a much smaller exercise than one covering several vendors and enrollment at scale. Timelines should be stated in the written, fixed scope rather than estimated from general assumptions, so ask any partner to show the phases, the change windows on each gateway and the acceptance tests for the pilot group. The client team's response times for approvals and access often set the schedule more than the technical build does.
What does the client team need to provide for a VPN MFA project?
The client team needs to provide three things early: administrative access to the VPN gateways so RADIUS clients can be configured and tested, read access to the user stores that privacyIDEA or FreeIPA will resolve, and named approvers who can sign off on the enrollment process, the pilot group and the cutover. Network paths between each gateway and the RADIUS servers must be open, and someone must confirm the change windows for each appliance. For token programs, the client should also decide who owns help desk procedures and where enrollment records are kept. Missing any of these items usually delays the project more than the technical build, so list them as client dependencies in the written scope.
Can an internal team set up open source VPN MFA without outside help?
An experienced internal team can set up VPN MFA alone if it has people who know the gateways, the directory and RADIUS, and if it has time to test failover and enrollment before go-live. The work is less about installing privacyIDEA or FreeIPA and more about correct RADIUS client configuration on each gateway, reliable user store mapping and a tested fallback so remote staff are not locked out during a RADIUS outage. Teams without recent experience with these areas often use an implementation partner for the design and testing, then keep operations in-house. Either model should be decided against the internal skills inventory and the number of gateways in scope.
What recurring work follows a VPN MFA launch?
After launch, the recurring work falls into three groups. The first is patching: privacyIDEA, FreeIPA, the operating system and the RADIUS path all need security updates on a schedule the client sets, and FreeIPA's release notes show that security fixes do arrive in minor releases. The second is token support, which covers lost devices, re-enrollment, unlocks and help desk time, and grows with the user count. The third is log retention, since VPN authentication records are often required as audit evidence, so retention periods and storage capacity must be decided and tested. Ask any partner to separate these items in the support proposal so the client can see which are fixed and which vary with usage.
Are there licensing costs for open source VPN MFA software?
The core components have open licenses, but licensing still needs review. privacyIDEA is licensed under AGPLv3 and is available as a self-hosted platform, and the project states that a privacyIDEA Enterprise Edition is available from NetKnights, so the client should confirm which edition covers the features in scope. FreeIPA is licensed under GPL-3.0-or-later and has no paid edition of its own. Push notifications need the privacyIDEA Authenticator app, so the client should check the terms of that app and any other client software before rollout. Any support subscription is a separate purchase that the client should see in the quote.
Which cost model fits VPN MFA best: build, partner or SaaS?
The right model depends on the number of gateways, the internal skills available and how much the client wants to own the operations. Building in-house keeps license spend low but puts integration, testing and recurring support on the internal team. A partner-run deployment moves design and testing into a fixed scope, with ongoing support sold separately if the client wants it. SaaS MFA charges per user and removes server work, but it may not fit a requirement to keep authentication data inside the client's own infrastructure. The MFA cost page compares these models in detail and lists the items to compare in each proposal.
How DeployOpen scopes and supports VPN MFA
DeployOpen plans, implements, integrates, hardens, backs up and documents a self-hosted privacyIDEA or FreeIPA deployment inside your own cloud accounts, data centers or air-gapped network. For VPN MFA, the scoping work starts with an inventory of every gateway that will send RADIUS requests (OpenVPN, Fortinet, Palo Alto and any others), the user store each one authenticates against, and the failure behavior you accept if the MFA server is unreachable. Those decisions shape the statement of work, so they should be settled in writing before any build starts. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing up front. Pricing follows from that written scope, and DeployOpen does not publish a price list.
Ongoing work after go-live is available as a retainer covering support, upgrades and continuous testing. For a RADIUS-based MFA service, the recurring items are platform upgrades, certificate and secret rotation on the RADIUS shared secrets, token enrollment for new staff, and periodic checks that the failover path still works. Ask any partner, including DeployOpen, to state in the proposal which of these are covered, who performs them, and how changes to gateway configuration are tracked. Confirm the upgrade policy for the privacyIDEA release line you choose, since current versions and support windows should be checked against the project's privacyIDEA releases page at the time of contracting.
DeployOpen prepares systems, controls and configuration evidence for compliance assessments, such as RADIUS authentication logs, gateway settings and enrollment records. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ask your auditor early which evidence they will sample for remote access, and agree on the log retention and export format before go-live so the evidence is usable later.
