Saviynt alternative for US public sector and FedRAMP

Saviynt alternative for US public sector and FedRAMP environments: the short answer

If you are an agency or a contractor choosing between Saviynt's FedRAMP Moderate offering on AWS GovCloud and self-hosted midPoint inside your own authorization boundary, the decision turns on who owns the control set, not on which feature list is longer. A FedRAMP authorization covers the cloud service provider's system for the federal information it handles, but it does not transfer your agency's obligations under NIST SP 800-53. Identity governance decisions such as who gets which role, who reviews access, and how deprovisioning is evidenced remain yours in either model. The question is which parts of the control implementation you inherit from a provider and which parts you must build, operate and document yourself.

With a FedRAMP Moderate SaaS service, a large share of the infrastructure, hosting and platform controls is inherited from the provider's authorization package, and your team concentrates on configuring the service, managing connectors and proving your own processes. With self-hosted midPoint, the platform itself is open source with no license fees, but the system security plan, hosting, patching, backup, logging, vulnerability scanning and access to the administrative interfaces all fall inside your boundary. Because the midPoint code is Evolveum's, the operating work and its evidence are your agency's or your contractor's. Confirm with your authorizing official and assessor exactly how your cloud and hosting environment is authorized before you assume any inherited controls.

Start with the requirements that drive the choice: whether your system handles federal information in a way that brings it within FedRAMP scope, whether any criminal justice information or controlled unclassified information under 32 CFR 2002 and CMMC requirements applies, and which NIST SP 800-53 baseline your system is categorized at. The sections below set out what FedRAMP covers, which controls stay with the agency, and what running midPoint in-house involves. For the platform itself, see the midPoint project site and confirm current release support before you commit.

What the constraint requires from an identity governance system

A federal or contractor deployment inherits controls from several frameworks at once: the federal control catalog, the statute behind it, the cloud authorization program and, for criminal justice or defense data, sector-specific rules. Each card below names one requirement and what it means for where your IGA runs and what evidence it must produce.

NIST SP 800-53 moderate baseline

NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B selects the controls for each impact level. The moderate baseline selects 287 controls and enhancements, and that count is the scope your system security plan must address for an IGA platform handling moderate-impact data. Ask Saviynt for its inherited control mapping for the FedRAMP package, then map every control it does not cover to a named owner inside your boundary when you run midPoint yourself.

FISMA and OMB A-130 as the legal basis

NIST lists FISMA and OMB Circular A-130 among the laws behind SP 800-53. Under FISMA, Inspectors General independently assess agency system security and report to OMB, so your identity system will be examined as a federal information system regardless of who built it. Confirm with your authorizing official which system boundary and authorization path applies before you choose between a vendor cloud and a self-hosted deployment.

FedRAMP scope under M-24-15

FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Systems used only for one agency's operations on cloud infrastructure, and not offered as a shared service, fall outside that scope. A self-hosted midPoint in your own accounts may therefore sit within your agency authorization boundary rather than under a FedRAMP package, so confirm that classification with your authorizing official in writing.

CJIS encryption and key length

CJIS Security Policy version 6.1 requires FIPS 140-3 validated modules, or FIPS 197 AES with at least 256-bit keys, for criminal justice information in transit and at rest outside physically secure locations. Any IGA deployment that holds CJI attributes, such as those tied to law enforcement roles, must use these modules end to end. Check the TLS termination, database encryption and backup encryption in midPoint's stack against this requirement, and confirm the validated module certificates for each.

CJIS monthly vulnerability scanning

CJIS Security Policy version 6.1 requires vulnerability scanning at least monthly, mapped to control RA-5. For a self-hosted midPoint, that scanning covers the Java runtime, the PostgreSQL repository, the web tier, the connector hosts and any Linux virtual machines or Docker images you deploy. Your operating team owns those scans and the remediation evidence, because no vendor SaaS scan will cover your hosts.

CMMC Level 2 cloud rules

Under 32 CFR 170.17(c)(5), a defense contractor seeking CMMC Level 2 may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. If your IGA stores CUI-linked identity data, a self-hosted midPoint within your own assessed scope can avoid the cloud service provider rule, but you must still show the controls are in place. Ask your C3PAO or assessor how the platform is scoped before you design the deployment.

Which Saviynt functions a FedRAMP boundary covers, and which open-source options fit

Saviynt's FedRAMP Moderate offering runs on AWS GovCloud, so the agency or contractor consumes Identity Cloud as a shared cloud service. FedRAMP authorizes the cloud service offering, meaning the infrastructure, platform controls and provider responsibilities documented in its authorization package. The authorization does not cover the agency's own access decisions, the connectors and identity data it configures, or the reviews its managers complete. Those stay with the agency under its FISMA Authorization to Operate, and the NIST control catalog in NIST SP 800-53 Rev. 5 describes how responsibilities split between provider and customer.

Covered by the authorization: the Identity Cloud service boundary and the controls the provider documents for it. Request the current package and the inherited control list.
Still owned by the agency: role design, certification campaigns, approver assignments and review of the logs it receives.
Module scope: Saviynt bundles governance, privileged access, application access governance and non-human identity management, so confirm which modules sit inside the authorized boundary.
Data location: confirm where identity data, logs and backups reside within GovCloud and which subprocessors touch them.
Contract terms: check incident notification and continuous monitoring deliverables in writing.

Confirm with Saviynt which modules and regions its FedRAMP Moderate package names before you map requirements to it.

How to deploy midPoint inside a federal authorization boundary

This sequence takes a team from defining the system boundary to a first evidenced certification cycle, so the agency or contractor can show that midPoint runs inside controls it owns. Each step ends with a check the reader can verify before moving on.

Confirm the system boundary and shared service status
Before choosing any software, the agency or contractor defines which systems, accounts, networks and personnel sit inside the authorization boundary, and records whether midPoint will serve only one agency's operations or be offered as a shared service. That answer determines whether FedRAMP scope applies, so confirm it with the authorizing official and, for contractors, with the contracting office. Done means a signed boundary diagram and a written scope statement that the assessor accepts.
Select the midPoint release and Java version
The platform team chooses between midPoint 4.8 (Curie), the long-term support release supported until October 17, 2028, and a supported feature release such as 4.10 (Braille), which is supported until November 26, 2027. Confirm the release against the midPoint releases page at the time of build, then pair it with the Java version midPoint documents for that release, Java 21 for 4.10 and older or Java 25 for 4.11 and later. Done means a pinned release and JDK recorded in the configuration baseline.
Size and isolate the PostgreSQL repository
midPoint uses PostgreSQL as its native repository, and the system requirements recommend running it on a separate database server. The team sizes the database host, storage and backup target against the expected identity count, places it inside the boundary with restricted network access, and configures encryption at rest that meets the cryptography requirements in the next steps. Done means a documented database host, tested restore from backup, and access limited to the midPoint nodes and administrators.
Build the multi-node deployment behind a sticky load balancer
The team deploys midPoint on Linux virtual machines or from Docker images, with at least two nodes behind a sticky HTTP load balancer that uses the shared central database. Cache invalidation between nodes runs over HTTPS, and Quartz handles distributed task scheduling so that a job runs once across the cluster. Done means a failover test in which one node is stopped and the session and provisioning jobs continue on the other.
Configure ConnId connectors for in-boundary targets
Each target system, such as Active Directory, LDAP, Entra ID through the Graph API or a SCIM2 endpoint, gets a ConnId connector configured with a dedicated service account following least privilege. Where a connector is listed as community or experimental rather than supported, the team reviews its code and tests it in a non-production environment before it touches live accounts. Done means each connector passes a reconciliation test against a copy of the target data and the results are logged.
Apply FIPS-validated cryptography and AES-256 where CJI applies
Where the workload handles Criminal Justice Information, the team confirms that the CJIS Security Policy version 6.1 requirements apply, then selects FIPS 140-3 validated modules or FIPS 197 AES with keys of at least 256 bits for CJI in transit and at rest outside physically secure locations. Confirm with the CJIS Systems Agency how these requirements are interpreted, and document the module certificate numbers used by the JVM, database and load balancer. Done means a cryptography inventory that maps each protected data flow to a validated module and key length.
Schedule monthly vulnerability scanning and patch cadence
The security team configures vulnerability scanning of every midPoint node, the database host and the load balancer at least monthly, as the CJIS policy requires for CJI environments, and tracks findings against the pinned release and its support end date. The team also schedules patch windows so the platform never runs past its support end date, which for midPoint 4.9 ended on October 18, 2026. Done means scan reports filed for each month and a tracked upgrade plan approved by the system owner.
Run the first certification cycle and collect evidence
The governance team runs a first access certification campaign against in-scope systems, records reviewer decisions, revocations and exceptions, and exports the audit logs and configuration baseline into the evidence store inside the boundary. The output is a dated package that maps each control, such as the access control and audit families of NIST SP 800-53, to the artifact that shows it operating. Independent assessors, not DeployOpen or Evolveum, decide whether the evidence is sufficient. Done means a completed campaign and an evidence index reviewed by the assessor.

Which NIST SP 800-53 controls stay with the agency

A FedRAMP authorization covers the cloud service the provider offers, not the way your agency configures and operates it. Whether you buy Saviynt's FedRAMP Moderate offering on AWS GovCloud or run midPoint inside your own authorization boundary, the controls that define who gets an account, how privileges are reviewed, how configuration changes are approved and how incidents are handled remain with the agency or are inherited only in part. Account management, audit review, least privilege, configuration management and incident response are the controls most likely to land on your team, because they depend on your role catalog, your approvers and your connector settings. Before comparing vendors, ask each provider for its customer responsibility matrix and map every control in your System Security Plan to one of three owners: provider, agency, or shared.

FISMA works independently of any vendor. Under that law, Inspectors General assess agency system security and report to OMB, so your IG will test whether your own identity processes work, whether or not a provider's authorization exists. A FedRAMP package does not satisfy that assessment for you. Plan evidence that your team can produce on request: certification campaign records, joiner, mover and leaver tickets, and privileged role review results. If you self-host midPoint, the evidence for these controls is generated inside your boundary, so the reviewer will look at your logs, your change records and your operating procedures directly.

NIST SP 800-53B selects control baselines, and OSCAL baseline profiles publish those selections in machine-readable form, which lets you tie each control to a responsible party in a structured way. Use the OSCAL profile for your impact level as the starting list, then record the inherited-control split in your SSP for each identity function. Be cautious about how far inheritance goes: a provider may inherit physical and infrastructure controls, but identity content in midPoint, such as role definitions and approval workflows, belongs to you. The exact split must be confirmed in the provider's documentation and in your agency's own System Security Plan, and reviewed with your authorizing official before you rely on it.

Evidence assessors and inspectors ask for under this constraint

Assessors and inspectors judge an identity governance deployment by its records, not by its feature list. The cards below cover the documents and logs that show who is responsible for each control, what sits inside the authorization boundary, and whether access was reviewed and changed as claimed.

System security plan and responsibility matrix

The system security plan describes the midPoint deployment, its boundary, data flows and the NIST SP 800-53 controls it implements. The control responsibility matrix states, for each control, whether the agency, the hosting provider, the integrator or a shared party holds the responsibility. For self-hosted midPoint, the agency usually owns most identity controls, so check that each control on the Rev. 5 moderate baseline has a named owner and evidence source before an assessor asks.

FedRAMP or agency authorization package

Any cloud component in the identity path, such as a hosted database, backup target or log store, needs its own authorization evidence. A FedRAMP authorization covers only cloud products that handle federal information on behalf of an agency, and it does not transfer to a self-hosted application running inside your boundary. Collect the authorization status, the boundary the provider covers, and the agency's authority to operate for the whole chain.

Access review and certification records

Certification campaigns, reviewer decisions, revocations and the timestamps of each step show that entitlements were reviewed on schedule. In midPoint these records come from the audit trail and the certification campaign objects, so confirm they are retained in your own database and can be exported with reviewer identity intact. Assessors often sample a few reviews and trace each decision back to the underlying account change.

Connector and change logs

Every provisioning action against a target system, from account creation to role removal, should be traceable to a request, an approval and a connector run. ConnId connectors write results that you can correlate with midPoint audit records, and change management tickets should reference the connector version deployed. Check that the target system logs show the same accounts midPoint reports, because a mismatch is the first finding an examiner raises.

Monthly vulnerability scan reports

Where criminal justice information is in scope, the CJIS Security Policy v6.1 requires vulnerability scanning at least monthly. Keep dated scan reports for the midPoint application host, the Java runtime, the database server and the load balancer, along with the remediation tickets for each finding. Name the scanner and its scope in the plan so the reports match the boundary described in the system security plan.

Encryption configuration evidence

Assessors check which cryptographic modules protect data in transit and at rest, not only that encryption is enabled. For CJI outside physically secure locations, v6.1 requires FIPS 140-3 validated modules or AES with 256-bit keys, so capture the TLS settings, database encryption configuration, key storage and the validation certificate numbers for each module. Include the configuration files and the key rotation records, since an unverified claim about a library version is a common gap.

Questions agencies and contractors ask before choosing midPoint over FedRAMP Saviynt

Does self-hosting midPoint remove the need for a FedRAMP authorization?

No. Self-hosting changes who operates the platform, not whether the system needs an authorization. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, and systems used only for a single agency's operations on cloud infrastructure, not offered as a shared service, are out of scope. An agency running midPoint inside its own authorization boundary should confirm with its authorizing official whether that deployment falls inside the agency's existing FISMA authorization process, and whether any contractor-operated part needs FedRAMP authorization at the Moderate baseline. Ask the authorizing official to confirm this in writing before design starts.

What does running midPoint cost compared with a Saviynt subscription?

midPoint has no license fees, since its code is published under the EUPL-1.2 and Apache 2.0 licenses. The cost is in components that recur or are one-time. Recurring costs include hosting in the agency's or contractor's boundary, database operations on PostgreSQL, staff who operate and patch the platform, an optional Evolveum support subscription (which offers 8x5 next-business-day or 24x7 SLA tiers, with no prices published on the page), and the assessment work needed to keep the system authorized. One-time costs include design, connector development for each target system, migration and testing. Costs rise with the number of connected systems, custom connectors and the depth of evidence required. Ask any implementation partner for a quote built from a written scope that lists each of these components separately.

How long does a midPoint deployment take in a federal environment?

No general duration is supported by researched facts, so the timeline should be set in a fixed-scope written plan rather than assumed. The duration depends on the number of authoritative sources, the connectors that must be built or validated, the number of roles and certification campaigns, the authorization package, and how many environments (development, test, production) must be assessed. Two items can be confirmed now: midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, and midPoint 4.10 (Braille) is supported until 26 November 2027, so the agency can choose a release with a known support window. Ask for milestones, acceptance criteria and dependencies on the agency's own approvals in the plan.

What does the agency or contractor need to provide before work starts?

Most of the inputs sit with the agency. It needs an authorization boundary and system security plan that name midPoint, its hosts, database and network paths, plus access to the authoritative sources (HR, directories, ticketing and target applications) and their owners. It also needs service accounts with least privilege for each connector, a decision on identity proofing and password policy, approved change windows, and staff who can approve roles and certification campaigns. On the infrastructure side, it needs virtual machines or container hosts that meet the recommended Java and PostgreSQL versions, a logging destination for audit records, and backup and key management that the authorization package can describe. Confirm each item in the written scope.

Can our own team run midPoint without an outside partner?

Yes, many organizations operate midPoint with internal staff, since the project is open source and its documentation covers installation, multi-node deployment and connectors. The practical question is whether the team has Java and PostgreSQL operations skills, identity engineering experience, and capacity to maintain connectors through upgrades. midPoint releases follow a feature cadence, and 4.9 support ends 18 October 2026, so upgrades must be scheduled into the operating plan. Evolveum sells support, consulting and training, and an outside partner such as DeployOpen can plan, implement, harden, document and support the platform inside the client's infrastructure under a fixed scope or a retainer. Decide which functions stay in-house before signing any contract.

How should a CMMC contractor scope midPoint for controlled unclassified information?

Under 32 CFR 170.17(c)(5), a contractor pursuing CMMC Level 2 may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. A midPoint deployment that the contractor hosts on its own systems is not a cloud service in that sense, so it is assessed within the contractor's own scope, but identity data that touches CUI still needs protection under NIST SP 800-171 requirements. If the contractor uses a hosting provider or managed cloud to run midPoint, that provider's service must meet the cloud rule. Confirm the classification of each host and dataflow with the contractor's CMMC assessor before the design is final.

What does midPoint not cover that a Saviynt suite provides?

midPoint is an identity management system, not an access management or SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. Agencies that rely on Saviynt for privileged access or application access governance should plan separate tooling for those functions. midPoint's documented scope includes provisioning and deprovisioning, lifecycle, role-based access control, auditing, self-service access requests, password reset, simulations and role mining. Connector coverage is documented for LDAP, Active Directory, Microsoft Entra ID, SCIM2 and others, while further connectors vary from supported to experimental. Ask for a connector inventory matched to each target system before the scope is signed.

What running IGA in-house takes after go-live

The first recurring cost of self-hosted midPoint is release tracking, and the calendar is set by Evolveum, not by the agency. midPoint 4.9 support ends on 18 October 2026, midPoint 4.10 (Braille) is supported until 26 November 2027, and midPoint 4.8 (Curie) is the long-term support release, supported until 17 October 2028. An agency that picks 4.8 buys a longer window between upgrades, while 4.10 requires an upgrade cycle sooner. The platform also moves its Java baseline: midPoint recommends Java 25 for 4.11 and later, and Java 21 for 4.10 and older. Each upgrade touches the JVM, the PostgreSQL database, the ConnId connectors and the customized objects, so the agency should plan a test environment that mirrors production and confirm with its team how long a full upgrade cycle takes in its own environment.

Within the authorization boundary, the agency or its contractor carries the patching and scanning work. Database patching for PostgreSQL, operating system patching for the Linux virtual machines or container hosts, and certificate renewal sit on the same schedule. For CJI in scope, the CJIS Security Policy version 6.1 requires vulnerability scanning at least monthly under RA-5, and the scan output must be triaged, tracked and retained as evidence. Access review cycles add a business-side load: each certification campaign needs reviewers, reminders, decisions and remediation tickets, and the number of reviewers grows with the entitlement count. Connector maintenance is the item most often underestimated. Each target system change, such as an Active Directory schema update or a new SCIM endpoint version, can break a ConnId connector, and custom connectors need Java developers who know the framework.

Staffing and effort must be confirmed against the agency's own scope, including the number of connected systems, the identity volume, the number of onboarding and offboarding events and the control baseline. Ask any integrator for a written breakdown of roles (platform engineer, IAM developer, security assessor support) and the hours each role covers per month. Evolveum offers Product Support subscriptions with an 8x5 next-business-day or 24x7 SLA for resolving product bugs, and Platform Subscriptions that add feature development and roadmap influence. Those subscriptions cover the software vendor's side of the work, not the agency's operations. Ask Evolveum for the current price and the terms that apply to your deployment and whether they fit inside your authorization boundary, and confirm with your authorizing official what ongoing monitoring evidence the agency must produce each period.

Primary sources for the federal requirements

NIST SP 800-53 Rev. 5 is the federal control catalog that most agency and contractor authorization work points back to. It is organized into control families, and the SP 800-53B baselines select which controls apply at each impact level. Current guidance is Release 5.2.0 of 27 August 2025, and the baselines select 149 controls and enhancements at low, 287 at moderate and 370 at high. The catalog is written in terms of the organization's own system, so it does not decide who operates a platform.

Baseline selection: SP 800-53B determines which controls are required for your system's impact level, and the OSCAL profiles let you import them into your tooling.
Federal law behind the catalog: NIST ties SP 800-53 to FISMA and OMB Circular A-130, which assign responsibility to agency heads.
Independent assessment: Under FISMA, Inspectors General assess agency system security and report to OMB, so your own evidence must withstand outside review.
Control inheritance: A cloud provider may inherit some controls, but the agency still owns the controls that describe its configuration and use.
Version pinning: Record which revision your system security plan cites, because the catalog is updated.

Confirm with your authorizing official which baseline and revision your system must map to before you assign any control to a vendor or to your team.

How DeployOpen deploys midPoint under a federal boundary

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For agencies and contractors weighing midPoint against Saviynt's FedRAMP offering, the work starts with agreeing which controls and evidence sit inside the client's own authorization boundary.

How we scope

Written scope fixes which midPoint functions, connectors and environments are in the engagement before work starts.
We map the agency's boundary, hosting account and data flows, and which NIST SP 800-53 controls the agency retains.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build begins.
Scope also records any PAM or application access functions that stay with other tools.

How we build

We install midPoint on Linux virtual machines or Docker images inside the client's own cloud account or data center.
Connectors are built or configured through the ConnId framework for the directories and applications in scope.
Testing covers provisioning, deprovisioning, role assignments and audit logging against agreed test cases.
We harden the PostgreSQL repository, multi-node layout and vulnerability scanning cadence to match the client's baseline.

How we hand over

Documentation covers architecture, configuration, connector inventory, backup and recovery steps, and operating runbooks.
Control evidence is organized for the client's assessors, who issue any audit reports or authorizations.
Knowledge transfer sessions train the client's administrators on daily operation and upgrade procedures.
Handover records list open items, owners and the upgrade path for midPoint releases the client plans to adopt.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover midPoint release upgrades, such as moving between supported long-term and feature releases.
Periodic security testing of the deployed identity platform can be scoped separately under the same engagement.
Support terms and response expectations are agreed in writing, so clients can confirm them against their own requirements.

Saviynt alternative for US public sector and FedRAMP environments