Key Vault to Key Vault Replication (PRO + ENTERPRISE)¶
PRO + ENTERPRISE Feature
Key Vault to Key Vault replication requires a PRO or ENTERPRISE tier licence.
Replicate Azure Key Vault items, secrets, certificates, and keys, from a source vault to a target vault within the same Azure tenant. One general-purpose feature covers three real use cases:
- Disaster recovery: keep a warm secondary vault in a different region
- Environment sync: promote curated items from dev to staging to prod
- Regional redundancy: reduce latency for geo-distributed workloads
When to Use Replication¶
| Scenario | Recommended Configuration |
|---|---|
| Primary → DR in another region | Secrets + certificates, all keys blocked cross-geography, propagate_deletes=false |
| Dev → Staging environment promotion | Pattern or tag rule, propagate_deletes=false, manual trigger |
| Regional read-replica inside the same geography | All item types, auto sync every 24h |
| Cross-tenant replication | Not supported: same-tenant only |
Same tenant only
Replication operates within a single Microsoft Entra ID tenant. Source and target vaults must both live in the tenant CertifyClouds is already connected to. Cross-tenant replication is not supported.
How It Works¶
Source Vault Target Vault
┌─────────────────────┐ ┌─────────────────────┐
│ prod-eu-kv │ │ prod-us-kv │
│ │ │ │
│ ├── db-password ────┼──── replicate ─────►│──► db-password │
│ ├── api-key ────────┼──── replicate ─────►│──► api-key │
│ ├── tls-cert ───────┼──── import cert ───►│──► tls-cert │
│ └── signing-key ────┼──── backup/restore►│──► signing-key │
└─────────────────────┘ └─────────────────────┘
│
▼
One record per item, each with its own status and history
Tenant scope and sync outcomes¶
With multi-tenant scope enabled, select one tenant before choosing New replication. An exclusion preview covers enabled secrets, certificates and keys; a certificate and its same-named backing key count once. Rules pinned to a replication preview only that source vault and its selected item types.
Syncs (30 days) counts the successful and failed runs from the last 30 days. Skipped runs stay in the history but are not counted in that total or in the success rate.
How a rule becomes records¶
A replication config represents a source → target vault pair with a rule (e.g. "all tagged with replicate=true"). When you save it, CertifyClouds lists every matching item as its own record, so you can see exactly what will be copied. This means:
- The records table shows exactly what will move, per item, with its current status
- Existing records matched by an exclusion show
excludedand keep their target copies. Removing the exclusion returns matching records to active management; manually paused records stay paused. A record that was disabled for no longer matching keeps that state while excluded so it can come back when it matches again. Excluded items that have never replicated do not create records. - Cross-geography and cross-subscription keys show a
blocked_*reason. Source items unavailable for replication stop matching; source-read failures are surfaced. - Two consecutive checks: an item has to stop matching twice in a row before its record is disabled, so a single missed scan never disables anything. Records disabled this way come back automatically when the item matches again; manually paused records stay paused
Per-Item-Type Flow¶
| Item type | Method | Attribute preservation |
|---|---|---|
| Secret | Copied with its value | expires_on, not_before, enabled, content_type, tags |
| Certificate | Import on target in the source's own format (PFX or PEM) | Full chain + private key, tags, enabled. Policy is not replicated, see limitations below. |
| Key | Key Vault backup on the source, restore on the target | All key attributes, rotation policy and key operations |
Key replication is same-geography and same-subscription only. Azure restores a key backup only into a vault in the same geography and the same subscription, so CertifyClouds blocks both cases up front rather than backing the key up and failing the restore (see Troubleshooting → cross_geography_key and cross_subscription_key). Secrets and certificates replicate across subscriptions normally.
Wizard Walkthrough¶
Navigate to Automation > Replication & Sync > Create config. The wizard is seven steps.
1. Target Type¶
Pick Azure Key Vault. AWS Secrets Manager, ACM, GCP Secret Manager, and GCP Certificate Manager are the non-Azure sync targets, this page is specifically the Key Vault → Key Vault flow.
2. Source Vault¶
Cascading dropdowns for subscription → vault name. Only subscriptions and vaults CertifyClouds has already discovered appear, if a vault is missing, run a Key Vault scan first (Assets › Scan › Run Scan).
3. Target Vault¶
Same selector for the target. Target vault must differ from source.
4. Validate Connection (required gate)¶
The wizard validates the connection server-side before allowing save. The validation result shows:
- Source geography and target geography badges
- Whether CertifyClouds can read from the source vault with its current identity
- Whether it can write to the target
- Whether source and target are in the same geography (affects key replication only)
- Any RBAC gaps or soft-deleted items
You cannot save the config until this step returns green. If it doesn't, see RBAC for the required role assignments.
5. What to Replicate¶
Two choices on this page:
Item types: checkboxes for secrets, certificates, keys. At least one must be selected.
Rule: how CertifyClouds decides what's in scope:
| Rule | When to use | Example |
|---|---|---|
all | Replicate every item in the vault | (no value) |
tagged | Only items with a specific tag | replicate=true or just replicate |
pattern | Glob match on item name | prod-* or api-key-? |
manual | Explicit list of names | ["db-password", "api-key"] |
Tag rules evaluate a single tag only, no AND/OR composition in v1.
6. Behaviour¶
- Overwrite target on conflict: off by default. When off, the first write to a target that already has an item with the same name waits as a Conflict until you acknowledge it. When on, the target item is overwritten straight away (the source wins). Only copies CertifyClouds created can later be removed by Propagate deletions; an item it overwrote never is. A soft-deleted item of the same name in the target cannot be overwritten either way: recover or purge it in Azure.
- Propagate deletions: off by default. When on, a copy CertifyClouds created is removed once its source item is permanently deleted. See Deletion Propagation.
- Update this copy right after a rotation: default on. When a rotation changes an item this replication copies, the copy is updated straight away. It is not in the wizard; change it later with the Replication behaviour action. See Copies after a rotation.
- Sync interval: 1 hour to 24 hours, default 24h. Existing sub-hour settings are treated as one hour. This controls how often each item syncs. Checks of the rule follow source scans or Check now, independently of the sync interval. Manual syncs are always available.
- Alerts: opt-in to email/webhook alerts for repeated failures, cross-geography blocks, and conflicts.
7. Preview¶
The wizard previews up to 1000 items with the status each would take (active, blocked by conflict, blocked by the cross-geography or cross-subscription key constraint, excluded by rule, etc.). Use this to sanity-check the rule before saving.
If the preview times out, the table is marked partial and the full check runs later.
Operating the Feature¶
Manual Triggers¶
- Replicate now (per record) - re-syncs one record. Labelled Retry when the last attempt failed.
- Replicate now (toolbar) - syncs all enabled records on the config.
- Check now - checks the current source inventory against the rule. Audit-logged. Only one check of a replication runs at a time: if one is already running, the request is refused with "check already running"; try again shortly.
- Pause (the toggle on a replication configuration) - stops its records from syncing. They are skipped without counting failures or sending alerts, and Replicate now on a paused replication is refused until it is enabled again.
- Acknowledge conflict - explicit click to unblock a record stuck in conflict state. Single or bulk.
Editing a Replication¶
Edit on a replication configuration reopens the wizard with its saved settings. You can change the name, item types, rule, behaviour and sync interval. The source and target vaults are locked; to replicate between different vaults, create a new replication.
Recreating a replication to the same target vault
Deleting a replication never removes its target copies, whatever Propagate deletions is set to: the copies stay in the target vault and simply stop being managed. If a new replication keeps the same target vault, its first write of each of those items therefore meets an existing live item and follows the normal conflict path - the record blocks as blocked_conflict until you Acknowledge conflict, or is overwritten straight away if Overwrite target on conflict is on. Nothing needs purging. The delete confirmation says the copies are kept and that removing them is a manual job in the target vault.
The preview compares the edit with the configuration's current records and marks each item Newly managed, No longer managed or Unchanged. Saving updates the configuration, applies a changed sync interval to existing records, and re-expands the rules straight away.
Deletion Propagation¶
Opt-in per config. When on:
- A copy CertifyClouds created is removed only once its source item is permanently deleted (purged, or its retention period has ended), and only after the item has been missing on two checks in a row.
- A source item that is soft-deleted (still recoverable), disabled, excluded or no longer matching the rule keeps its copy. A disabled source item shows Source disabled and syncing pauses until it is re-enabled.
- Standalone keys are never deleted. Propagation and exclusions both keep a replicated key in the target vault, whatever happens to its source. Only secrets and certificates are ever removed.
- If CertifyClouds cannot confirm that the source item is gone, it deletes nothing and tries again on the next check. Repeated failures send the replication failure alert.
- If you switch propagation off, change the replication or delete it while a check is running, deletions that were about to happen are skipped and recorded in the audit log.
- Items CertifyClouds only adopted or overwrote are never deleted by propagation, even with Overwrite target on conflict on.
- Deleting the replication itself deletes nothing in the target vault. Propagation only governs removal of copies whose source item was permanently deleted, while the replication is running. Deleting the configuration removes the configuration and its records; every copy it created is kept in the target vault and stops being managed, and the delete result says so. Remove those copies manually in the target vault if you no longer want them.
In-app purge of target items is not exposed in v1, blast radius is too high. If a soft-deleted target is blocking a first write, the UI provides an Open Azure Portal ↗ deep-link to the target vault's deleted items blade for manual purge.
Correlation IDs¶
Every check and sync has a correlation ID, recorded with the run in the audit log. Quote it when you contact support so we can find the exact run straight away.
Limitations¶
The following are not currently supported:
- Cross-tenant replication: same-tenant only
- Bidirectional replication: source is always source-of-truth
- Cross-geography key replication: Azure
backup/restoreis same-geo only; applies to software and HSM keys alike - Certificate policy or issuer replication: only the current certificate is copied, and copies never renew in the target vault
- Key / certificate / secret version history: latest version only
- Event Grid push triggers: interval polling only
- BYOK workaround for cross-geography keys
- Forced purge of soft-deleted target items: use the Azure Portal deep-link
- AND/OR tag rule composition: single tag only
- Per-record scheduling: config-level interval only
- In-app purge of target items
Related¶
- RBAC reference, required Azure role assignments for source and target
- Troubleshooting by error code, every stable error code with a fix
- Custom role JSON: source
- Custom role JSON: target