Residency is written about storage and tested on the key

A residency clause describes a location. It tells you which country the records must sit in, and a storage tier inside that country satisfies it as written. The evidence an assessor asks for later is a different kind of fact. It is about who holds the key that turns those records back into readable text, where that key was generated, and whether anyone outside the country can be instructed to produce it. Those two halves are procured separately.

Where the rule is written and where it is tested

The instruction arrives as a sentence about storage. It names a country, applies to records at rest, and a database replica inside that country answers it. The test comes later, and it is a different one. Someone asks what would happen if a party outside that country were told to hand over readable copies. The answer does not turn on where the ciphertext is. It turns on who can perform a decryption.

That is the half a software key manager leaves open. A key held in software is a sequence of bytes inside a running process. Those bytes can be read by the process, written into a memory dump when it crashes, wrapped into a backup and restored onto a machine somewhere else. None of that looks like an attack. Possession of the key is the entire requirement for decryption, so whoever holds the bytes holds the records, whatever the hosting contract says about location.

What the hardware changes, and what it does not

A hardware security module inverts the direction of the request. The key is generated by the device, stays there, and the application sends its data in instead of asking for the key. What comes back is a signature or a ciphertext. A compromised application can ask the module for operations while it holds its credentials, and it cannot carry away the ability to perform them later, because it never had the key to carry. Custody also becomes physical. The key acquires a serial number, a rack and a country, and the people who can stand next to it are a list you can hand an assessor.

What the device does not settle is the procedure around it. The PCI PTS HSM Modular Security Requirements v4.0 state that HSMs are typically housed in a secure environment and managed with procedural controls external to the device, and that the document covers device management only up to receipt at the point of deployment. How many custodians authorise a key export, whether remote administration is switched on, and what protects the backup wrapping key are your decisions, not the certificate's. A key that never leaves the module in the clear can still leave it wrapped, and if the wrapping key sits with a service in another country, the question has moved rather than closed.

What a certification asserts when a tender names one

A Common Criteria certificate is issued against a Security Target, a document stating what the product claims to do and what it assumes about its environment. The evaluation assurance level attached to it is a package of assurance requirements, and it fixes how deeply the evaluators had to look, not how much security the product contains. CC:2022 Part 5 names EAL4 "methodically designed, tested and reviewed" and describes the scale as balancing the assurance obtained against the cost and feasibility of obtaining it.

The plus sign is worth asking about. Part 5 calls it augmentation, meaning assurance components added from families the package does not contain, or replaced by higher ones from the same family, with the claimant obliged to justify each addition. Two devices both written up as EAL4+ can carry different augmentations against different Security Targets, so the comparison a buyer can make is between those documents rather than between two identical strings.

Recognition is the second thing to check. The Common Criteria Recognition Arrangement recognises certificates claiming compliance with a collaborative Protection Profile carrying assurance activities up to level 4 and ALC_FLR, or with Evaluation Assurance Levels 1 through 2 and ALC_FLR. Where a certificate confirms components above that, the Arrangement requires it to be marked "CCRA recognition for components up to EAL 2 and ALC_FLR only". An EAL4+ certificate therefore rests on the national scheme that issued it.

PCI HSM makes a different kind of statement. It is a list of criteria the device is tested against, called in the standard the minimum acceptable criteria for the Payment Card Industry, written to reduce the likelihood of fraud and limit its consequences rather than eliminate it. One of its logical requirements is that the device must not be able to output a clear-text PIN encryption key. Read that from the residency side. A device with no command for emitting a key in the clear cannot be talked into emitting one by anybody who reaches it over a network.

The standard is modular, which matters once a hosted service is quoted. Core requirements, key-loading devices, remote administration and life cycle security are separate modules, and v4.0 added one for cloud-based HSMs as a service with multi-tenant usage and remote management requirements. A v3.0 approval predates that module. Approvals also expire. In a bulletin dated 2 March 2026 the PCI Security Standards Council pushed the v3 device approval expiration from April 2026 to April 2028, and the v4 expiration from April 2032 to April 2033.

Four clauses that are key custody questions in other words

The phrase key custody may not appear in the tender. What appears is language about storage, control and approval.

• "Records must be stored inside the country." Ask whether key material and the operation that uses it fall inside that sentence, or only the ciphertext does.
• "The institution retains sole control of its encryption keys." Ask whether the key can exist outside the device in any form, and which key protects the backup copy.
• "Cryptographic operations must run on an approved device." Ask which module of the standard the approval covers, because a hosted service and a rack appliance fall under different ones.
• "Administrative actions require dual control." Ask how many custodian credentials the device itself enforces, and whether remote administration sits inside the approved configuration.

Where the request goes when the data becomes a prompt

An organisation can spend three years moving its records into a chosen region, then add a model endpoint that sends the same records back out in an afternoon. A prompt is a copy of the data. The questions are the ones already on this page, asked about a workload instead of a disk. Where does the request travel, where is it processed, is anything retained afterwards, and on infrastructure chosen by whom.

When the answer mentions encryption, the follow-up is the same one. Who can produce the key. Bringing your own key means you generate it and import it into the provider's key store, where the provider's service performs the operation with it. Holding your own key means the key stays in your device and the provider's service calls out to it each time work is needed. The difference is whether a copy of the key has crossed the boundary, which is the mechanism payment systems have run on for years, pointed at a newer workload.

Where this sits in the portfolio

Data and cryptography is the area this question belongs to, and the key custody half of it sits with Procenne. The ProCrypt HSM family generates keys inside the device and performs encryption, decryption and signing there, so an application sends work in and gets a result back. CryptAway clusters devices from more than one manufacturer behind a single interface, so capacity can be added without retiring installed hardware. The product page names Common Criteria EAL4+, PCI HSM v3.0 and PCI HSM 4.x, with signing to XAdES, PAdES and CAdES.