Migrate from PingFederate to WSO2 Identity Server

When PingFederate moves to WSO2 Identity Server, and what that takes

Choose WSO2 Identity Server when PingFederate still carries WS-Federation relying parties that Keycloak cannot replace. Keycloak covers OpenID Connect, OAuth 2.0 and SAML 2.0, but WS-Federation is the gap that matters here, and WSO2 Identity Server lists WS-Federation among its supported protocols alongside SAML, OpenID Connect and SCIM. Before you commit, inventory every connection in your PingFederate configuration and tag the ones that use WS-Federation or WS-Trust. If that list is short and every other connection moves to Keycloak, a split estate may be simpler than a single WSO2 platform. Identity architects usually own that decision, with platform engineers handling hosting and the owner of each relying party confirming its claims and token expectations. WSO2 Identity Server is licensed under Apache-2.0, but a supported commercial deployment comes with a separately paid WSO2 subscription that covers expert support, continuous updates and vulnerability monitoring. Confirm the subscription terms with WSO2 for your deployment model before you build a cost case.

The effort depends less on the protocol than on the adapters and attribute contracts behind each connection. Each WS-Federation relying party needs its claim rules, token lifetimes and signing certificates rebuilt on the WSO2 side, and each one needs a test that a real user session completes before cutover. Plan the user store early. WSO2 can read from a relational database, an LDAP directory such as Active Directory or OpenLDAP, or a custom user store, so confirm whether PingDirectory or another directory stays as the source of truth or whether identities move. The main risk is a relying party that depends on a PingFederate-specific attribute or signing behavior nobody documented. Run both platforms in parallel for each connection, and do not retire a PingFederate connection until its owner has signed off a successful login and a clean rollback path. The WSO2 installation documentation lists supported JDK and database versions, which your platform team should check against your standards before sizing the environment.

Which PingFederate capabilities map to WSO2 Identity Server, and which need rework

This table maps the PingFederate capabilities most likely in use to their WSO2 Identity Server equivalents and labels each as clean, needs rework or gap. Read the labels as a starting point for planning, since adapter-specific logic and WS-Trust dependencies can only be settled in a proof of concept against your own connections.

Capability	PingFederate today	WSO2 Identity Server	Status
SAML 2.0 service provider connections	SP connections with SAML assertion templates and signing certificates	SAML 2.0 service provider configuration with claim mapping and signing settings	Clean
OpenID Connect and OAuth 2.0 clients	OAuth clients, scopes and access token management	OIDC and OAuth 2.0 applications with scopes and token settings	Clean
WS-Federation relying parties	WS-Federation SP connections serving legacy relying parties	WS-Federation is supported, but each relying party needs its own configuration and test	Needs rework
WS-Trust token dependencies	STS token issuance for WS-Trust clients, where present	Not assumed to match PingFederate behavior; confirm token types and endpoints in a proof of concept	Gap until confirmed
SCIM provisioning	Outbound or inbound SCIM connections, where configured	SCIM 2.0 support for user provisioning; confirm the schema extensions and endpoints each consumer expects	Needs rework
IdP and SP adapters	Custom adapters that read sessions or set attributes for apps	No direct adapter equivalent; authentication logic is rebuilt as WSO2 authenticators, scripts or custom components	Gap
Attribute contracts and claim rules	Attribute contracts, data store lookups and OGNL or script-based mappings	Claim mappings and attribute configuration per application; scripted rules need manual translation	Needs rework
LDAP and Active Directory user stores	Directory connections to LDAP or AD	LDAP and Active Directory user stores, including OpenLDAP, supported natively	Clean
Relational database user stores	JDBC-backed data stores with custom queries	Relational database user stores on supported databases; confirm custom query behavior and password hashing	Needs rework

What moves cleanly and what does not

Standard SAML and OIDC relying parties are the easy part of this move. A connection that uses a known assertion consumer service URL or OIDC redirect URI, signs with a certificate you can re-issue, and asks only for attributes you can map one to one is usually a re-registration task in WSO2 Identity Server. Start by listing each such connection with its protocol, redirect or ACS URI, signing and encryption certificates, audience values, and the exact attribute list it expects. Those five fields are enough to recreate the service provider or application in WSO2 and to test it with a single sign-on flow. Confirm each attribute name in the relying party's own configuration, because a renamed claim is the most common silent failure in a federation cutover.

WS-Federation relying parties and anything tied to custom PingFederate code need individual validation. The WSO2 Identity Server documentation lists WS-Federation among its supported protocols, but support for a protocol does not guarantee that a given relying party will accept the tokens it produces. Check the exact WS-Federation token type, the claim URIs and their order, the lifetime and audience restrictions, and any signing or encryption choice the relying party relies on. Where a connection depends on a PingFederate adapter, a token processor, or a WS-Trust behavior that another system assumes, treat it as a rebuild rather than a copy and document the replacement in your own words. Run each WS-Federation relying party against a test tenant, capture the token it receives, and compare it with the token it received from PingFederate before cutover.

Plan for the connections that cannot be validated in time to hold a cutover date. Keep those relying parties on PingFederate during a staged move and record which dependency is blocking each one, such as a custom adapter, an undocumented claim transform, or a vendor application that cannot change its expectations. Ask the vendor of any packaged application whether it has been tested with WSO2 Identity Server for WS-Federation, and confirm the answer in writing. Review your own developers' integrations as well, since code that parses a token directly is often invisible in the inventory. The output of this review should be a per-connection decision: move as is, rebuild, or retire.

Which exports and integrations to move from PingFederate

The move starts with a complete inventory of what PingFederate actually does for your organization. The configuration export is the starting point, but it does not capture everything, so each card below names an item to inventory and an item to source again before cutover.

The configuration archive as a starting point

Export the PingFederate configuration archive from the administrative console and treat it as the base list of connections, OAuth settings and certificates. Compare its contents against your running server, because the archive is a snapshot and may not reflect changes made by other administrators or pending updates. Record the PingFederate version and the date of the export so you can explain later which configuration you migrated.

Connections across SAML, OIDC and WS-Federation

Build one register of every service provider and relying party, with its protocol, endpoint, binding and owning team. WS-Federation relying parties are the entries most often missed, because they are often older applications that rarely change and may not appear in a current SAML or OIDC report. Mark each entry as active, retired or unknown, and confirm the unknowns with the application owners before you map anything.

OAuth clients and signing certificates

List each OAuth client with its grant types, redirect URIs, scopes and whether it is confidential or public. Inventory every signing and token certificate, its expiry date and the relying parties that trust it, since a certificate that expires during cutover can break logins without warning. Plan new keys in WSO2 Identity Server and schedule the switch-over of each relying party's trust, rather than copying private keys between servers without a rotation plan.

The user directory behind PingFederate

Identify where PingFederate reads users: an LDAP directory, a relational database or both. WSO2 Identity Server supports a relational database, an LDAP directory such as OpenLDAP or Active Directory, or a custom user store, so you can often keep the existing directory and avoid moving identities. Confirm attribute names, password handling and group membership, because claims sent to relying parties depend on them.

Adapters, drivers and license to source again

Adapter drivers, templates and the PingFederate license file do not carry over in the configuration archive. Record every custom adapter and the authentication logic it performs, then decide whether WSO2 Identity Server's built-in authenticators or a custom implementation will replace it. Obtain any required drivers from their owners and confirm your WSO2 subscription or open-source build choice before you rely on either.

The migration sequence from inventory to decommission

This sequence moves WS-Federation, SAML and OIDC relying parties from PingFederate to WSO2 Identity Server one connection at a time, keeping a tested rollback path until every relying party is confirmed on the new platform. Each step closes with a written artifact that the next step depends on.

Inventory every relying party and protocol
Start by listing every connection PingFederate serves, including WS-Federation relying parties, SAML service providers, OIDC clients and OAuth clients. For each one, record the protocol, the attributes sent, the signing and encryption certificates, the user store it reads from, the owning team and any downstream dependency such as a legacy application that expects a specific claim. Ask application owners to confirm the list, because connections that are rarely used are often missed. The output is a connection register that is agreed with the owners. The step is done when every active connection has an owner and a protocol, and each dormant connection has a documented retirement decision.
Map adapters and attribute contracts to WSO2
For each entry in the register, document the PingFederate adapter, the attribute contract and any token processing rules, then map them to WSO2 Identity Server equivalents: service providers and inbound authentication configuration, claim mappings, and the user store that supplies each attribute. Note any custom adapter logic that has no direct equivalent and needs a rewrite or a separate design decision. The output is a mapping document that a security reviewer and the application owner both sign off. It is complete when every attribute in every contract has a target claim or an approved reason for dropping it.
Pilot one WS-Federation and one OIDC connection
Choose one WS-Federation relying party and one OIDC client that have a test environment and a willing owner. Configure both in a non-production WSO2 Identity Server environment, then compare the issued tokens with the tokens PingFederate issues for the same test user. Check the issuer, audience, lifetime, claim values and signature. Run the login flow end to end, including logout and session expiry. The output is a validated token contract for each protocol, recording the claims the relying party accepts. The pilot is done when the relying party logs users in without changes to its code beyond the agreed configuration.
Decide the directory and user store strategy
Confirm where each population of users authenticates on the new platform. WSO2 Identity Server can use a relational database, an LDAP directory such as OpenLDAP or Active Directory, or a custom user store. Decide whether the identities stay in their current directory or move, and test password and account state behavior for the pilot users. Use a production-grade database such as PostgreSQL, MySQL, Oracle or Microsoft SQL Server, since the embedded H2 database is for development and testing only. The output is a written directory decision and a tested read path. It is complete when pilot users authenticate against the chosen store.
Run both platforms in parallel
Keep PingFederate serving its existing relying parties while WSO2 Identity Server serves the migrated ones. Route each migrated relying party to the new platform by changing its metadata or endpoint configuration, and keep the PingFederate configuration unchanged so it can be restored. Monitor authentication success, error rates and token rejections on both sides. Write a rollback plan for each relying party that states the exact configuration to revert, the owner who approves a rollback and the signal that triggers it. The output is a monitored parallel run with a rollback plan on file for every connection moved.
Cut over relying parties in waves
Move the remaining relying parties in groups, starting with those that carry the least risk and ending with the most business-critical ones. Schedule each cutover with the application owner, confirm the post-cutover login test, and record the result in the connection register. Keep the previous PingFederate configuration available until the owner confirms a clean period of use. The output is an updated connection register in which every relying party shows its platform, cutover date and sign-off. The step is done when no relying party depends on PingFederate for authentication.
Retire PingFederate and archive its configuration
Once no connection remains, stop routing traffic to PingFederate and export its configuration archive for retention. Note that the archive holds private keys and must be stored under the same controls as other secrets, and that it does not contain every component, such as adapter drivers or the license file, so keep those separately if your records require them. Remove the PingFederate certificates from relying party trust stores, revoke or rotate any credentials that could still authenticate to it, and close the subscription or support agreement only after the archive is verified. The output is an archived configuration, a closed decommission record and a revised certificate inventory.

The WSO2 subscription question: community build or supported deployment

The first decision in this migration is not technical: it is whether your WSO2 Identity Server will run as a do-it-yourself build from the open source code or as a supported commercial deployment. WSO2 publishes the Identity Server source under Apache-2.0 and offers an unsupported open source distribution on GitHub. That distribution is suitable for evaluation, a proof of concept or a team with strong internal engineering capacity, but it carries no vendor support, and it does not come with the continuous product updates, vulnerability monitoring and expert support that a regulated federation hub usually needs. Your team would own patching, security advisories and troubleshooting for every WS-Federation relying party that depends on it.

A WSO2 on-prem subscription changes that split. According to the wso2/product-is README, the subscription provides expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Before you commit, ask WSO2 in writing which of these items are included at your tier, what the response expectations are, whether updates cover the Java and database versions you plan to run, and how commercial use is defined for your deployment model. Confirm whether the subscription covers Kubernetes, virtual machine and bare-metal installs in the same way, and whether it applies to non-production environments. Pricing is quoted per subscription, so the cost driver to request is the scope you need, not a list rate.

Treat the subscription as a recurring line item alongside the one-time migration project. The migration effort, the cutover testing for each WS-Federation relying party and the operations work on the JDK, database and certificates recur regardless of which build you choose. Ask WSO2 for a quote that states the deployment topology, the number of environments, the support tier and the update policy, then compare it against the internal staffing you would need to run the community build to the same standard. Your own security team should confirm the vulnerability monitoring and patch timelines they require for the environment before deciding.

What drives the cost and duration of the move

This table lists the components that shape the effort and spending for a PingFederate to WSO2 Identity Server move, who is paid for each, and what to request in a quote. Use it to build the written scope before comparing proposals, since most of the cost comes from the number and type of connections and the deployment choices.

Driver	Why it changes cost or effort	Who is paid for what	What to ask for in a quote
Number of relying parties	Each SAML, OIDC or WS-Federation connection needs its own configuration, testing and cutover window. The count sets most of the implementation effort.	Implementation partner for mapping and testing; your team for owner sign-off and business validation.	A per-connection estimate with the protocol and test approach stated for each one.
WS-Federation versus SAML and OIDC mix	WS-Federation relying parties often need token claim rules and metadata handling that differ from SAML and OIDC, so they usually take longer to verify.	Partner for claim rule and metadata work; application owners for testing their own apps.	Separate line items for WS-Federation, SAML and OIDC connections, with the test cases each one requires.
Custom PingFederate adapter logic	Custom adapters, password credential validators and token processors must be re-expressed in WSO2 terms. Adapters with business logic take more analysis than standard ones.	Partner for analysis and rebuild; your developers if custom Java code is involved.	A list of each custom adapter with an assessment of whether it is rebuilt, replaced or retired.
User store complexity	Relational databases, LDAP directories and Active Directory each carry different attribute, schema and replication concerns. Multiple stores multiply the mapping and reconciliation work.	Partner for user store configuration and validation; directory team for source data quality.	Confirmation of each user store type, the attributes used by each relying party and the reconciliation method.
Database choice (Oracle, PostgreSQL, MySQL or Microsoft SQL Server)	WSO2 Identity Server supports these databases. Your existing licensing, DBA skills and backup tooling determine whether a database is a new cost or a reused one. The embedded H2 database is for development and testing only.	Database licensing if you use a commercial engine; DBA time for schema setup and tuning.	Confirmation of the database engine, licensing status and whether production will use a managed or self-run instance.
Deployment target (Kubernetes, Docker, VM or bare metal)	Each target brings different build pipelines, high availability design, load balancing and patch processes. Kubernetes adds cluster operating skills if your team does not already run it.	Your infrastructure team for hosting; the partner for installation, clustering and runbooks.	The chosen target, the high availability topology, and who operates the hosts after handover.
Subscription decision	WSO2 offers an unsupported open source distribution for self-built deployments, and commercial subscriptions include expert support, continuous product updates and vulnerability monitoring. The choice affects recurring cost and who responds to incidents.	WSO2 for the subscription, if chosen; your team or a partner for the unsupported path, including patch testing.	Written subscription terms, the support scope, update cadence and the difference in responsibility between supported and unsupported builds.
Parallel running and cutover	Running PingFederate and WSO2 side by side adds licensing time for the old platform and a longer testing period. Application-by-application cutover reduces risk but extends the timeline.	Your team for the ongoing Ping subscription; the partner for coexistence design and rollback steps.	The cutover order, the length of the coexistence period you plan for, and the rollback criteria for each application.

What usually goes wrong and how to prevent it

PingFederate migrations to WSO2 Identity Server tend to fail at the edges: token contents, signing material, directory attributes and the cutover itself. Each risk below has a concrete check you can run before a relying party goes live on the new server.

Token claims differ from what relying parties expect

A relying party may depend on a specific claim name, format or ordering that PingFederate emitted, and WSO2 Identity Server can produce the same information in a different shape. Capture a live sample token or assertion from every connection, then compare it field by field with what the application parses. Run the comparison against a test relying party before changing DNS or endpoints.

Forgotten WS-Trust dependencies

WS-Federation relying parties are often paired with WS-Trust token services, such as STS calls from desktop clients, legacy middleware or SharePoint-style integrations. Those dependencies rarely appear in the list of SAML and OIDC connections, so they break silently after cutover. Search access logs and application configs for token endpoints before you declare the inventory complete.

Signing keys and certificates left behind

Relying parties trust a specific signing certificate, and an identity server that generates a new key pair will fail signature validation everywhere at once. Decide whether the existing certificate and private key will be imported into the WSO2 keystore or whether every relying party will receive new metadata. Confirm the expiry dates of every certificate and set a dated plan for each rotation.

User store attribute mismatches

Attribute names, multi-valued fields and identifier formats often differ between the directory behind PingFederate and the WSO2 user store, which can be a relational database, LDAP or Active Directory. A missing mail or userPrincipalName mapping produces sign-ins that succeed but return empty claims. Map each attribute the relying parties consume and test with accounts that have unusual values, such as missing department fields or shared mailboxes.

Embedded H2 database in production

WSO2 Identity Server ships with an embedded H2 database that is intended for development and testing only. Teams that start a pilot on the default setup sometimes keep it when they go live, which leaves session, token and configuration data on a store that is not suited to production. Plan for a supported relational database such as PostgreSQL, MySQL, Oracle or Microsoft SQL Server from the first build, and document the JDK version against Java 21 or Java 25.

Cutover without a rollback path

Moving every relying party in one change window removes the ability to return users to PingFederate when a claim or certificate problem appears. Keep PingFederate running and move connections in small groups, with a documented DNS, metadata or endpoint switch for each one. Agree a rollback decision point in writing before the first group moves, and keep the PingFederate configuration archive until the last connection is confirmed.

How the move differs by starting point

When most connections already use SAML 2.0 or OpenID Connect and only a few relying parties need WS-Federation, the WSO2 move is a narrow exception rather than a full rebuild. The bulk of the work is a standard application-by-application cutover, and WSO2 handles the protocols that are already in use. The WS-Federation relying parties should be isolated early so they do not hold up the rest of the plan.

Sequence the common protocols first: Move SAML and OIDC applications in waves, using the same cutover pattern for each wave.
Scope the WS-Federation exceptions separately: Identify the few relying parties that need WS-Federation and plan their connections as a distinct track.
Check attribute contracts per application: Confirm the claims or assertions each relying party expects, since they are rebuilt in WSO2 rather than copied.
Keep the parallel run short for simple apps: Low-risk applications may need only a brief period where PingFederate and WSO2 both serve them.
Decide early whether Keycloak can take the SAML and OIDC share: Splitting the estate across two platforms adds operating cost, so the decision should be made before build work starts.

Before committing, confirm with the team which relying parties truly require WS-Federation, because a smaller WS-Federation set can change the platform decision.

Questions buyers ask before moving PingFederate to WSO2

What does moving PingFederate to WSO2 Identity Server cost?

The cost has four main parts: the WSO2 subscription or a self-built deployment, the infrastructure to run it, the migration project, and the ongoing operations team. WSO2 offers an unsupported open source distribution on GitHub for do-it-yourself builds, while commercial deployments receive updates for enhancements, fixes and performance plus expert support. The one-time cost is mostly the migration work: inventorying connections, rebuilding each WS-Federation relying party, and testing. The recurring cost is the subscription (if you choose one), hosting, and staff time for upgrades and monitoring. Ask any proposal to split these lines, state whether the WSO2 subscription is included, and list the assumptions behind the number of relying parties and user stores.

How long does a PingFederate to WSO2 migration take?

Duration depends mainly on how many relying parties you have, how many of them use WS-Federation rather than SAML or OIDC, how much custom adapter logic must be rebuilt, and how many user stores feed the directory. Applications with simple SAML or OIDC settings move quickly, while WS-Federation relying parties with custom claim rules need more analysis and testing. Running PingFederate and WSO2 side by side during cutover adds time but reduces risk. No fixed duration applies to every estate, so request a timeline in the written scope after the inventory is complete, and ask which assumptions it depends on.

What must our team supply before the migration starts?

The team needs four inputs before design work begins:

A complete inventory of PingFederate connections, OAuth clients, certificates and adapter configurations, including the WS-Federation and WS-Trust dependencies.
A named owner for each relying party who can confirm claims, endpoints and cutover windows.
Test access to each application in a non-production environment, with test accounts and the ability to validate sign-in end to end.
Access to the user stores, such as the relational database, LDAP or Active Directory directories that feed authentication today.

An export of the PingFederate configuration helps build the inventory, but it does not capture everything, so check it against the live system. Missing owners and test access are the most common reasons a schedule slips.

Can our own team migrate PingFederate to WSO2 without a partner?

A team with identity engineering experience, access to the relying party owners and a clear test plan can carry out the migration internally. The hard parts are WS-Federation claim rules, certificate and trust handling, and user store integration, which need people who know both the old and new platforms. Consider an external partner when the team lacks WSO2 or WS-Federation experience, when many applications share the same risk profile, or when the change window is tight. DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your infrastructure, and most engagements are fixed-scope with the scope and deliverables agreed in writing before work starts.

Is a WSO2 subscription required to run Identity Server in production?

No subscription is required by the open source license, since the WSO2 Identity Server source code is licensed under Apache-2.0. The question is what you give up without one. The unsupported GitHub distribution is intended for do-it-yourself builds, and it does not come with expert support, continuous product updates or vulnerability monitoring. A WSO2 on-prem product subscription adds those services and access to the licensed distribution for commercial use. Decide based on your ability to patch, monitor and troubleshoot the platform in-house, the regulatory expectations for vendor support in your sector, and your tolerance for running an unsupported build in production. Confirm the current terms directly with WSO2 before you commit.

How does Keycloak compare for the SAML and OIDC connections?

Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it has built-in user federation with existing LDAP and Active Directory servers, so the SAML and OIDC connections are usually the easier part of a PingFederate exit. Keycloak is licensed under Apache License 2.0 and is a CNCF incubating project. The reason WS-Federation changes the decision is that Keycloak alone does not cover WS-Federation relying parties. A common split is to move SAML and OIDC applications to Keycloak and keep WS-Federation relying parties on WSO2 Identity Server, which adds a second platform to operate. Alternatively, put all connections on WSO2 if WS-Federation is widespread. Map each connection to its protocol before choosing.

What should we check first in the WSO2 user store setup?

Start by confirming which directories hold the identities that PingFederate relies on today. WSO2 Identity Server user stores can be a relational database, an LDAP directory such as OpenLDAP, Active Directory, or a custom user store implementation. Check attribute mappings, password policies, group membership and how the directory is replicated. Verify that the production database is one of the supported options, such as PostgreSQL, MySQL, Oracle or Microsoft SQL Server, because the embedded H2 database is for development and testing only. Confirm the JDK version required by the release you choose, since WSO2 Identity Server requires a Java 21 or Java 25 compliant JDK. Test authentication for a sample of real accounts before cutover.

What are the main risks when cutting over WS-Federation relying parties?

The main risks are claim mismatches, certificate and trust errors, and sign-in failures that only appear with production data. Each WS-Federation relying party may expect specific claim names, token lifetimes and signing certificates, so a small difference can block sign-in for a whole application. Run both platforms in parallel, test each relying party with its owner, keep a documented rollback path for each cutover, and record evidence of the tests. Secure the admin console and signing keys from the start, and confirm the logging and monitoring you rely on work on the new platform. DeployOpen can prepare systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or attestations.

How DeployOpen scopes and runs a PingFederate to WSO2 move

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports WSO2 Identity Server inside the client's own infrastructure, whether that is a Kubernetes cluster, virtual machines, Docker hosts or bare metal. Most engagements run under a fixed scope agreed in writing before work starts, and that document fixes the deliverables, the connection set in scope, the environments and the timelines. For a PingFederate move, the written scope should name the WS-Federation relying parties, SAML and OIDC connections, OAuth clients, user stores and the cutover approach, so the quote can be traced to specific items rather than to a general estimate.

The scope conversation starts with the inventory. Ask for the PingFederate configuration export and the list of relying parties, then confirm which ones use WS-Federation, which need claim rules that depend on custom adapters, and which user store each one reads from. Each open item becomes a line in the scope. DeployOpen does not publish a price list, so the quote follows from that written scope. Ask any provider, including DeployOpen, to price the connections, the user store integration, the hardening and backup work, the cutover support and any post-go-live retainer as separate lines. Confirm with WSO2 which subscription tier covers your deployment before the quote is final, because support and update terms are set by WSO2, not by the implementation partner.

After go-live, ongoing support, upgrades and continuous testing are available as a retainer, which suits the cadence of WSO2 releases and vulnerability work. Agree in writing who applies product updates, who monitors vulnerabilities, how backups are tested and who owns the runbook for certificate rotation. DeployOpen prepares systems, controls and documentation for compliance assessments, but it does not issue audit reports or certifications; your independent auditor or certification body makes that determination. Put that boundary in the scope so evidence requirements are clear from the start.