Why self-hosted secrets management for EU data sovereignty changes the design
Self-hosted secrets management under EU control is achievable with OpenBao or Infisical, but the decision turns on key custody, access by third-country authorities and license terms, not on features alone. An EU organization whose encryption keys and application secrets sit in a US cloud KMS, and whose legal or security team now questions that arrangement, is asking a question about who can compel access, not only about where data is stored. The GDPR transfer rules in Chapter V and the US CLOUD Act reach providers that hold data in their possession, custody or control, so the provider's jurisdiction matters even when the bucket is in Frankfurt. A secrets manager deserves particular attention because it holds the keys that unlock other systems. Whoever can read those keys can often read the databases, backups and pipelines they protect.
That makes the design questions concrete. The first is custody: who holds the unseal and recovery material, whether it can be split across EU-based officers, and whether the cluster runs in the entity's own data center or an EU cloud account the entity controls. The second is access: the EDPB's Recommendations 01/2020 state that where a provider needs data in the clear and the destination's powers exceed what is necessary and proportionate, no effective technical supplementary measure can be envisioned, so the design should avoid giving any external operator plaintext access to key material. The third is licensing. HashiCorp Vault from version 1.15.0 is under the Business Source License 1.1, which is not an OSI-approved open source license, while OpenBao is under MPL-2.0 and Infisical's core is MIT with a separate enterprise license for ee directories. Ask counsel to confirm which terms apply to the exact features you plan to use.
Before choosing a product, run three checks. Map every secret and key store that currently sits with a non-EU provider and note which ones hold keys for personal data. Ask the current provider in writing where key material is stored, who can operate the service and how it responds to foreign authority requests. Then confirm that the target design keeps all key material, audit logs and administrative access inside EU-controlled infrastructure. Where the answers still leave doubt, a legal review of the transfer analysis should come before any migration. DeployOpen can prepare the technical evidence for that review, but the legal conclusion belongs to the organization and its advisers.
Which EU rules shape key and secret custody
This table maps each EU rule in scope to what it means for where keys and secrets are stored, who can reach them and what evidence the build must produce. Read each row as a design question: if the answer is a US-controlled service, the row tells you what that choice exposes. The main takeaway is that data location alone does not settle the question, because remote access, legal reach and key control also count.
| Requirement | What it means for the build | Evidence to prepare |
|---|---|---|
| GDPR Article 44 and Chapter V transfers | Any transfer of personal data to a third country, including onward transfers, needs a Chapter V basis. Secrets that unlock personal data sit inside that scope, so a key service hosted outside the EEA needs a transfer assessment. | Transfer register entries, data location map for key and secret stores, documented transfer basis |
| Remote access from a third country | EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer. Vendor support staff outside the EEA with console access therefore count. | Support access matrix, named locations for administrators, session logs for vendor access |
| GDPR Article 48 limits on disclosure orders | A third-country court or authority order to disclose personal data is enforceable in the EU only under an international agreement such as a mutual legal assistance treaty. Your design should assume that foreign orders alone do not bind you. | Documented legal review of any non-EU provider, contract terms on government requests |
| CLOUD Act reach under 18 U.S.C. 2713 | US providers must preserve or disclose data in their possession, custody or control, wherever it is stored. Hosting keys in an EU region of a US cloud does not remove this exposure, so confirm who holds the keys and the provider's legal control. | Provider jurisdiction analysis, key ownership statement, contract clauses on disclosure notice |
| EU Data Act Article 32 on non-personal data | Providers of data processing services must take measures to prevent third-country governmental access to non-personal data held in the Union where it would conflict with EU or national law. Secrets metadata and configuration can fall under this rule, so ask the provider how it meets it. | Provider's Article 32 measures in writing, data residency statement, internal review record |
| Data Act switching rights | Customers may move to another provider or to on-premises infrastructure, with notice and transition periods set by the regulation, and switching charges are banned from 12 January 2027. Self-hosted OpenBao keeps the exit path under your control, and export of secrets and policies should be tested before you need it. | Exit plan, tested export of policies and secret metadata, contract terms on switching |
| NIS2 Article 21(2)(h) cryptography and key management | Entities in scope need policies and procedures for the use of cryptography and, where relevant, encryption, including key management. A self-hosted secrets manager supports key lifecycle, access control and audit logs inside the entity's own infrastructure, but the policy itself is the entity's responsibility. | Cryptography and key management policy, key lifecycle records, access control and audit log samples, rotation evidence |
| Attestation boundary | DeployOpen plans, builds and documents these controls and prepares evidence for assessment. It does not issue audit reports, attestations or certifications, and independent auditors or the competent authority make that determination. | Written scope of the evidence pack, named assessor or auditor, agreed deliverables before work starts |
When a US cloud KMS becomes a transfer and access question
Storing encrypted data in a US cloud provider's key management service is a different question from holding the key material itself, and the second one is where EU data sovereignty risk concentrates. A provider that can decrypt on your behalf can be compelled to disclose what it holds, even when the ciphertext sits in an EU region. The CLOUD Act provision at 18 U.S.C. 2713 requires providers to preserve or disclose data in their possession, custody or control regardless of where it is located, so the question for a secrets or key manager is who controls the key material and who can be made to hand it over. EDPB Guidelines 05/2021 treat remote access from a third country and storage outside the EEA as transfers under Chapter V of the GDPR, so an external KMS that is operated from or reachable by a US entity needs a documented transfer assessment before it holds any key that protects personal data.
The Court of Justice of the EU, in Case C-311/18 (Schrems II) on 16 July 2020, invalidated the Privacy Shield while holding that standard contractual clauses remained valid, but the EDPB's Recommendations 01/2020 are the sharper constraint for keys. They state that where a cloud provider must access data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption does not rescue a KMS whose operator needs the plaintext key to serve requests. The EU-US Data Privacy Framework, set by Commission Implementing Decision (EU) 2023/1795, covers only US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending against the General Court's September 2025 judgment upholding it. Confirm the current list status of any provider and treat the appeal outcome as an open risk.
For a self-hosted OpenBao deployment, the practical decision is where the unseal material, the root of the encryption chain and the operators with administrative access sit. Ask whether any US-parented vendor, support engineer or hosting contract can reach those components, and document the answer. Get counsel's reading on whether your specific transfers, processors and supervisory expectations require a transfer impact assessment or other measures. This page is not legal advice, and the conclusions here depend on your data, your contracts and your regulator.
OpenBao and open-core options compared on license and control
For EU data sovereignty, the license decides who can change the code, host it and keep running it without a vendor's permission. The options below differ on that question, and each needs a check against the edition you intend to deploy.
OpenBao under MPL-2.0
OpenBao is a community-driven fork of Vault, licensed under MPL-2.0 and hosted as a Sandbox project of the OpenSSF under Linux Foundation stewardship. For a sovereignty case, that combination means no single vendor controls the roadmap or the license terms. Confirm that the features you need (auth methods, HA backend, audit devices, namespaces) are present in the release line you will run, and check the migration guide if you are moving from Vault.
Infisical and its enterprise directories
Infisical is licensed under MIT, except for content in ee directories, which carries a separate enterprise license. The open core covers secrets, certificates and access in a self-hosted deployment, but features placed under ee may be restricted by license terms. Ask your counsel to map each capability you need to either the MIT scope or the enterprise license before you design around it.
HashiCorp Vault under BSL 1.1
Vault 1.15.0 and later is distributed under the Business Source License 1.1, with IBM named as licensor. The BSL is not an OSI-approved open source license, so using Vault in a sovereignty program is a commercial licensing decision, not a default open-source choice. Confirm the license terms for your intended use, including any restrictions on hosting or competing offerings, and document the result for your procurement and legal teams.
Edition-specific license review
Open-core projects can change what each edition includes, so the license of the repository is only the starting point. Compare the edition you plan to run with the features your design needs, such as SSO for administrators, audit log export, HSM integration and multi-tenant controls. Request the written license for the exact edition and version in the quote, and record which features are covered by each license.
Control over operations and exit
Self-hosting only supports sovereignty if the organization can run, patch and migrate the platform without vendor consent. Assess who holds the upgrade path, which storage backend you will operate (OpenBao supports integrated storage, PostgreSQL, PebbleDB and in-memory), and whether you can export secrets and policies if you leave. Under the EU Data Act, switching to on-premises infrastructure is a customer right, so your exit plan should match it.
Governance and support contracts
An open license does not guarantee support, security response times or long-term maintenance. Ask which versions receive security fixes, how advisories are published, and whether a commercial support contract is available for the components you choose. Record these answers alongside the license review so that your risk assessment covers both legal rights and operational continuity.
How the rollout moves keys out of the US cloud KMS
The sequence moves keys, secrets and certificates from a US cloud KMS into a self-hosted OpenBao cluster in EU infrastructure, with a signed decision, a tested cluster, a migration register and a retirement record at each stage. Cloud KMS keys are retired only after the evidence that replaces them has been captured.
Inventory keys and secrets by sensitivity and jurisdiction
The client's security lead and data owners list every key, secret and certificate that protects personal data, including the cloud KMS keys, the application secrets that call them, and the copies held in CI/CD and configuration. Each entry is tagged with the data it protects, the processing location, the systems that read it, and any third-country support or administrative access path that could reach it. DeployOpen's delivery team reviews the list with the client's legal and privacy function. The output is a signed inventory and a design decision record that states which items must stay in the EU and which can move first. Done means every item has an owner, a jurisdiction tag and a named decision.
Decide the custody model for unseal and recovery material
The client's security and key-custody owners decide how unseal keys, recovery keys and administrative tokens will be split, stored and used, and who must be present to use them. Options range from split custody held by named EU-based staff to hardware-backed storage where the client's policy requires it. The decision also records whether any external service, including a cloud KMS, can ever hold or see this material. Confirm with the OpenBao documentation and the client's own environment how the chosen mechanism works before it is written into policy. The output is a signed custody design and a runbook draft. Done means no unseal or recovery material depends on a non-EU service unless the client has documented and accepted that dependency.
Deploy and test an HA cluster in EU infrastructure
The DeployOpen team installs OpenBao in the client's EU cloud accounts, data center or private network. The team selects a storage backend from those OpenBao documents, either integrated storage (Raft) or PostgreSQL, based on the client's operating skills, and configures an active node with standby nodes. Failover, seal and unseal behavior, backup restore and TLS are tested against the written design before any production data is placed in the cluster. The output is a tested cluster with recorded test results, backup and restore evidence, and an updated architecture diagram. Done means the cluster has passed failover and restore tests that the client's operations team has witnessed.
Map each application and pipeline to an auth method
Engineers list every application, service account, pipeline and administrator that reads secrets today, then assign an OpenBao auth method to each. OpenBao documents AppRole for servers, JWT/OIDC for pipelines and workloads, Kubernetes for cluster workloads, and login MFA for people. Policies are written per application so that each identity can read only the paths it needs. The output is a migration register that links each consumer to its current secret source, its new auth method, its policy and its owner. Done means every consumer has an entry and no consumer is left on a shared static credential without a documented exception.
Migrate consumers and rotate secrets during cutover
Each application is moved in a controlled change window, starting with the lowest-risk consumers, while the old cloud KMS path remains available for rollback. Secrets are rotated after cutover so that values copied from the old source are no longer valid. Where data is encrypted with cloud KMS keys, the team plans re-encryption with keys held in OpenBao, validates decryption on a sample, and then re-encrypts the remaining data in batches. The output is a rotation log and a re-encryption record for each data store. Done means every migrated consumer reads from OpenBao in production and the register shows the rotation date for each secret.
Export audit logs to the client's SIEM
The team configures OpenBao audit devices so that every secret read, write, key operation and login is recorded, and forwards those logs to the client's SIEM or log store inside the EU. Log retention, access to the logs and tamper protection are agreed with the client's compliance owner. The team confirms that events from both the old cloud KMS and the new cluster are retained during the overlap period. The output is a log routing configuration, a sample of recorded events, and a retention statement. Done means the SIEM shows reads from each migrated consumer and the compliance owner has accepted the retention settings.
Retire cloud KMS keys after evidence capture
Cloud KMS keys are scheduled for disablement only after the register shows every consumer migrated, every secret rotated, every data store re-encrypted, and the audit trail has been exported and checked. The team captures the final inventory, the cluster test results, the custody decision, the audit samples and the cloud provider's key deletion or disablement record. The client's security lead signs a retirement record that lists each key, its replacement and the evidence location. Cloud KMS contracts and data processing terms are reviewed with legal, since the client's own supplier records also change. Done means the retirement record is signed and stored with the design decisions.
Evidence a regulator or auditor will ask for
This table lists the evidence items a regulator or auditor is likely to request about keys and secrets held under EU control, the component that produces each item, and what the reader should confirm. Use it to plan which logs, policy files and records must exist before an assessment starts. It does not state that any single item satisfies a specific audit or regulation.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Register of keys and secrets | Each key, secret and certificate, its storage location, owner and the jurisdiction of every host and backup | Inventory maintained in the ticketing system, reconciled against OpenBao mounts and storage backend locations |
| Transfer and third-country access assessment | Whether any copy, backup, support session or vendor access places key material outside the EEA or under third-country law | Written assessment in the GRC or ticketing record, with contract and hosting location evidence |
| License review record | Why the chosen license (OpenBao under MPL-2.0 or an open-core option) fits, and which enterprise directories are excluded | Dated review memo stored with the architecture decision record |
| Access policies and auth method configuration | Who can read or manage each secret path, and which auth methods (AppRole, JWT/OIDC, TLS certificates) are enabled | Policy files under version control, auth method configuration exports |
| Audit logs of key use | Each read, write, encryption-as-a-service call and unseal event, with identity and timestamp | OpenBao audit devices forwarded to the SIEM, with retention set by the entity |
| Rotation records | When keys and credentials were rotated, by whom or by which automated process, and any failed rotations | OpenBao rotation and lease logs, plus change tickets for manual rotations |
| HA and backup test results | Evidence that a standby can take over and that backups restore into the entity's own infrastructure | Test runbooks and signed results in the ticketing record, with backup job logs |
| Data Act switching plan | How the entity would move keys and configuration to another provider or on-premises infrastructure, and the notice and transition steps | Written exit plan maintained by the entity, reviewed against the Data Act articles |
Questions buyers ask about EU key custody and self-hosting
What drives the cost of moving off a US cloud KMS?
The cost depends mostly on how many applications, certificates and keys depend on the cloud KMS today, and how many of them call it directly in code. The main components are infrastructure for the self-hosted cluster (compute, storage, backups and a second site if you need high availability), the migration work per application (changing how each workload fetches and decrypts data), and the operations time to run, patch and monitor the platform after go-live. Some costs are one-time, such as design, migration and testing. Others recur, such as hosting, staff time and support. Ask any partner for a quote that splits these into one-time and recurring lines, names who performs each task, and lists the applications in scope. Check your current cloud KMS invoices as well, since per-key and per-call charges are part of the baseline you are replacing.
How long does a secrets and key migration take?
The timeline is set by the inventory of keys and secrets, the number of applications that need changes, and how much of your change process has to be followed for production systems. Migrations usually run in phases: first the platform build and testing, then low-risk workloads, then regulated or business-critical systems, and finally decommissioning the old KMS keys once every dependency has moved. Re-encrypting existing data can take longer than configuring the new service, especially for large datasets. No general duration applies to every organization, so ask for a timeline built from your own inventory and a written scope. Also confirm how the plan handles the period when both systems run in parallel.
What does the client team need to provide for this work?
Your team supplies the knowledge of your systems and the decisions only you can make. Typical inputs include an inventory of applications, databases and pipelines that use the cloud KMS, owners for each system, approval for change windows, and the people who will hold unseal or recovery material and approve access policies. You also need someone who can approve the target architecture, define key ownership and rotation rules, and sign off on evidence for auditors. Expect your security, platform and application teams to be involved during testing. Ask a partner to list these roles by name in the scope so that gaps are visible before work starts.
Can our own team run self-hosted OpenBao without a partner?
A capable platform team can run OpenBao after it is built, but it needs ongoing skills in cluster operations, storage, certificates, access policies and incident response. The areas most often underestimated are unseal and recovery procedures, backup restore testing, upgrades, and how audit logs reach your monitoring. Ask yourself whether you have people who can perform a restore under pressure and whether they have time for upgrades every few months. A partner can take on the initial design, implementation, hardening, documentation and support retainer, while your team keeps custody of keys and approves changes. The split should be written down so responsibilities are clear during an incident.
Is OpenBao or Infisical easier to clear in an EU license review?
For a license review, OpenBao's core repository is licensed under MPL-2.0 and is hosted under the OpenSSF, which many legal teams find straightforward to assess. Infisical is licensed under MIT, but content in its ee directories carries a separate enterprise license, so you must confirm which features your deployment uses and whether they fall under that license. Neither choice removes the need for legal review of your specific use. Ask counsel to check the exact license files for the version you plan to deploy, to map each feature you need to its license, and to record the decision. Also consider whether the project's governance matches your procurement policy and your long-term exit plan.
Does self-hosting remove all third-country exposure from our keys?
No. Self-hosting moves custody to your infrastructure, but third-country exposure can remain through support access, remote administration, vendor telemetry, software updates, and any cloud or data center provider you use. EDPB guidance treats remote access from a third country, even just displaying data on a screen for support, as a transfer. Control support access by limiting who can open remote sessions, requiring approval and session recording, keeping break-glass accounts under your custody, and writing these rules into contracts. Also review whether the infrastructure provider or any subcontractor is subject to third-country law with extraterritorial reach, since that can affect what they must disclose. Ask your partner to document every path by which a non-EU person could reach keys or metadata.
What to ask an implementation partner before signing
Start with the keys that matter most: the unseal and recovery keys for your OpenBao cluster. Ask the partner where each share or auto-unseal key material will be held, which named people or roles can reach each share, and whether any single person or vendor account can reconstruct the root of trust. Ask for the split between unseal shares and recovery keys, the custody procedure for each, and how access is logged and reviewed. If the design depends on a cloud KMS for auto-unseal, ask which provider and region hold that key and whether the key sits under EU control. A partner that cannot answer these questions in writing before work starts is not ready to hold your keys.
Next, test the exclusion of third-country access in writing. Ask how the design blocks remote administration from outside the EEA, including vendor remote support sessions, screen sharing, bastion access and emergency break-glass accounts. Ask who at the partner can log in to your environment, from which countries, through which jump hosts, and under what approval. Ask for the written scope and deliverables, the named roles that will touch production, and how each engagement step is recorded. Also ask how the partner assesses any third-country law with extraterritorial reach that applies to its own staff, tooling or support contracts, and what it does when a foreign authority requests data. Keep these answers in your third-party risk file.
Then cover exit and licensing. Ask how the partner plans for the Data Act switching right, including data export formats, the two-month notice and 30-day transition described in the Act, and how the switching charges ban that applies from 12 January 2027 affects the contract. Ask which edition and license apply to each component, and whether the team has reviewed the MPL-2.0 license of OpenBao and any open-core modules you might add. Ask how the HA backend is tested: which storage backend is chosen, how failover and restore are rehearsed, and what evidence is produced. Finally, ask how audit logs reach your SIEM and where that data is stored, confirming that the log pipeline stays in the EU and that the export is tested end to end.
Integration points that keep keys inside the EU
A self-hosted OpenBao deployment keeps keys in the entity's infrastructure only if every connection around it stays under the same control. The six points below cover how workloads, staff and pipelines authenticate, where data is stored, how audit records leave the cluster, and how emergency access is handled.
Authentication for servers and workloads
OpenBao documents AppRole as the method it recommends for servers, so a host proves its identity with a role ID and a secret ID that can be delivered and rotated separately. Kubernetes and TLS certificate methods cover workloads that already carry platform-issued identity. Check that every method is configured against identity sources you run, and that no path depends on a third-country identity service to issue a token.
Pipeline login through JWT and OIDC
CI runners can authenticate to OpenBao with a short-lived JWT or OIDC token issued by the pipeline platform, which removes stored credentials from job variables. The trust configuration decides which projects and branches can obtain which secrets. Confirm that the OIDC issuer for your pipelines runs on infrastructure you control, or that the issuer's token signing keys are reachable and documented for your auditors.
Staff login through LDAP or Kerberos
Administrators and engineers should sign in to OpenBao with the directory your organization already runs, such as LDAP or Kerberos, with MFA enabled at the login step. Personal accounts give unique user identification, which the HIPAA Security Rule and similar frameworks expect. Check whether the directory is hosted inside the EU, how group membership maps to OpenBao policies, and how leavers lose access the same day.
Storage backend and data location
OpenBao encrypts values before they reach storage, but the backend still holds ciphertext, metadata and the lock for the active node. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and the docs describe PostgreSQL as easier to operate safely. Choose a backend whose hosts, backups and replicas sit in EU locations you name in the contract, and confirm where every backup copy is kept.
Audit pipeline to the SIEM
Every secret read, lease and policy change should produce an audit record that leaves the cluster in near real time and is kept under a retention rule you set. The risk is a silent gap: if the audit device fails, OpenBao can block requests, so confirm the failure mode and the forwarding path. Ask who can read the audit store and whether the SIEM that receives it is itself hosted in the EU.
Internal PKI and break-glass access
Internal certificates for services and devices can be issued by OpenBao's PKI engine, so the certificate authority and its private keys stay in your environment. Pair this with a documented break-glass procedure: sealed unseal material held by named custodians in separate locations, a dual-approval rule for emergency root use, and a recorded test of that procedure. Confirm who holds each unseal share and how quickly a custodian can be replaced.
How DeployOpen scopes and supports an EU key custody build
This sequence turns an EU data sovereignty requirement into a written, fixed scope for OpenBao or another self-hosted secrets platform, then carries it through build, handover and ongoing support inside the client's own infrastructure.
Map keys, secrets and data flows
DeployOpen's architects inventory every secret type, key and certificate the organization holds, along with the systems that use them, the regions where they run and any path that could carry data or remote access to a third country. The client's compliance and legal teams review the map, and the output is a signed data flow register that shows where key material is generated, stored and used. The step is complete when each location has a named owner and an EU or national jurisdiction assessment that the client has accepted.
Decide platform and custody model
Working from the register, DeployOpen compares OpenBao under MPL-2.0 with open-core options such as Infisical, whose ee directories carry a separate enterprise license, and documents the licensing, governance and support trade-offs for the client's procurement and legal teams. The decision also covers who holds unseal material, whether an HSM is needed, and which storage backend fits the operating model. The output is a written architecture decision record that the client signs before any build work starts.
Agree fixed scope and deliverables
DeployOpen issues a written scope that lists the environments, auth methods, integrations, migration of existing secrets, backup and recovery tests, and documentation to be delivered. The client and DeployOpen agree the timeline and acceptance criteria in writing before work begins, and any item outside the list needs a change request. Ongoing support, upgrades and continuous testing are priced separately as a retainer, so the client can see one-time and recurring costs side by side. The step closes when both parties sign the scope.
Build and harden inside the client environment
DeployOpen deploys the chosen platform into the client's own cloud accounts, data centers or isolated networks, with high availability, encrypted storage, network restrictions and administrative access controls configured to the agreed design. Unseal and recovery material is split so that no single person or service can reopen the vault alone. The step is complete when a hardening checklist has been run and each finding is either fixed or recorded with an accepted risk owner.
Migrate secrets and connect audit logging
DeployOpen moves existing secrets out of code, configuration files and shared spreadsheets, replaces static credentials with dynamic or leased ones where the target system supports them, and routes audit logs to the client's monitoring platform. Each application is tested against its new authentication method before the old credential is revoked. The output is a migration log, a list of remaining static secrets with owners and a sample of audit events that proves every read is recorded.
Test backup, restore and recovery
DeployOpen restores backups into a separate environment and rehearses unseal and key recovery with the staff who will own the platform after handover. The client confirms that recovery works without access to any service or cloud key service outside the agreed jurisdiction. The output is a signed test report listing what was restored, how long the client observed it taking, and any gaps that need a follow-up change.
Document controls and prepare evidence
DeployOpen writes the runbooks, key lifecycle procedures, access policies and architecture records, and assembles evidence that maps these to the controls the client must demonstrate to its assessor or regulator. DeployOpen prepares the evidence but does not issue audit reports, attestations or certifications, so the client confirms with its auditor which artifacts they will accept. The step is complete when the client's compliance lead signs off the evidence pack.
Hand over and support under retainer
DeployOpen runs a handover session with the client's operations team and, if agreed, moves into a retainer for upgrades, security patches, periodic restore tests and continuous testing. The retainer scope, response expectations and any service levels are written down before handover, and the client should ask for them explicitly in its quote. The step closes when the client's team performs a supervised key rotation without DeployOpen's help.
