The customer designates a storage region for cryptographic material. The enterprise is configured to use KMS keys and a CloudHSM in that region.
The region must support both KMS and CloudHSM; Bunker validates the configuration at enterprise setup.
Backup ingestion, enrollment, and the TEE all run against region pinned keys. Ciphertexts persist in regional multi zone storage.
The customer stores their FIDO2 hardware devices in the same jurisdiction, closing the loop on the customer domain.
Recovery operations execute entirely against regional components; no share or ciphertext crosses the jurisdictional boundary.
Verification reports give the regulator or customer standing proof that every component required for recovery remains within the jurisdiction.
Tenant keys created and held in the designated region. Decryption requests resolve regionally.
The operations HSM share lives in a single tenant HSM in the same jurisdiction, in a distinct AWS account.
Multi zone durability inside the region; fingerprints verified by the standard scanning process.
The customer keeps FIDO2 devices in region; check ins prove their continued availability.
Attestation the customer can hand to a regulator: components exist, verify, and reside where required.
Data residency is enforced at the key layer, not by policy promise: the KMS keys and HSM physically reside in the region.
The customer owns the last mile: hardware tokens must actually be stored in the jurisdiction for the guarantee to hold end to end.
Regional pinning constrains the multi region durability strategy to multi zone within the region; the fingerprint scanning cadence is unchanged.
This pattern typically pairs with the check ins reference architecture to give the regulator continuous, verifiable evidence.
Walk through the trust model, policy design, and rollout with our security and solutions team.