Key Vault references for connection secrets

File-ingestion connection secrets (SFTP passwords and keys, SAS tokens, storage account keys and connection strings) can be stored as Azure Key Vault references instead of being persisted in D365, so the secret lives only in Key Vault, rotates centrally, and never sits in the database. A Key Vault reference needs an AOS server that can sign in to your vault with its own Azure identity, which only environments whose servers run in your own Azure subscription have; see Where Key Vault references work. A secret entered on the connection itself is stored encrypted with the platform encryption service instead, and works in every environment.

How a secret is stored

A connection holds its secret in one of these ways. The read-only Secret storage field on the File ingestion connections page shows which:

Secret storage	What's stored	Resolved by
Azure Key Vault reference	AuthSecretKvRef (up to 255 characters): a secret URI such as https://{vault}.vault.azure.net/secrets/{name} (see Reference format)	fetched live from Key Vault with the AOS server's Azure identity
Encrypted	AuthSecret: the secret, encrypted with the platform encryption service (Global::editEncryptedField, the mechanism the platform uses for the email SMTP password)	decrypted in-process; the key belongs to the environment, so any AOS or batch server can decrypt it
Not set	nothing	no secret (an Azure Blob connection with an Endpoint then signs in with the AOS server's managed identity, which has the same requirement as a Key Vault reference)

Every caller (the pull jobs, Test connection and the APIM bulk export upload) reads the secret through MGCLatticeFileIngestSecretProtector::resolveConnectionSecret, which detects the mode and routes accordingly, so every consumption point supports Key Vault references with no per-caller change.

How the fetch works

For a Key Vault reference, Lattice:

1. Checks that the reference is a Key Vault secret URI (see Reference format); any other address fails before a token is requested, so the token is never sent to another host.
2. Acquires a token for the Key Vault scope of the vault's cloud (https://vault.azure.net/.default for *.vault.azure.net, and the matching scope for a sovereign-cloud vault) with DefaultAzureCredential on the AOS server. On an Azure virtual machine, that is the machine's managed identity, so no credential is stored anywhere.
3. Reads the secret with GET {secretUri}?api-version=7.4 and the bearer token.
4. Uses the secret's value.

The PGP private key and passphrase references on a connection (PGP private key (Key Vault reference), PGP passphrase (Key Vault reference)) are resolved the same way, and follow the same reference format.

A resolution failure is thrown (label FileIngestKeyVaultResolveFailed), never swallowed into an empty secret, so a bad reference or a missing access policy is visible immediately.

Where Key Vault references work

Lattice reads Key Vault with the Azure identity of the AOS server itself. It does not use the standard Key Vault parameters page of Finance and Operations.

• Environments whose servers run in your own Azure subscription, such as a cloud-hosted environment that Lifecycle Services deployed to your subscription: enable the system-assigned managed identity on each virtual machine that runs the AOS or batch, and grant each identity access as described in Setup.
• Microsoft-managed environments (the sandbox and production environments that Microsoft runs through Lifecycle Services, and environments managed in the Power Platform admin center): Microsoft operates their servers and gives you no AOS identity that you can grant access to your vault. In this release a Key Vault reference cannot be resolved there; store the secret on the connection (Encrypted) instead. The same applies to the managed identity option of an Azure Blob connection.
• On-premises environments: servers outside Azure have no managed identity, so store the secret on the connection (Encrypted).

Setup (one-time, per environment)

1. Grant the managed identity of each AOS and batch server access to the vault: a Key Vault Secrets User role assignment (RBAC) or a get secret access policy. This is the only trust link; there is no client secret to rotate.
2. Store the secret in Key Vault as the same JSON document you would otherwise type in the Authentication field, for example { "sasToken": "sv=..." } or { "username": "lattice", "privateKey": "..." }. The value is parsed as JSON; a bare key or token that is not a JSON document is not used as a credential.
3. On the connection, type the secret's URI (https://myvault.vault.azure.net/secrets/mysftpkey) in the Authentication field and save. The URI is kept in AuthSecretKvRef as a reference and any encrypted secret on the connection is cleared; Secret storage then shows Azure Key Vault reference. Select Test connection to prove the environment can read it. Rotate by adding a new secret version in Key Vault, with no D365 change.

Security notes

• Nothing secret is persisted in D365 in Key Vault mode: the database holds only a vault URI.
• Central rotation: rotate in Key Vault; the next ingestion run reads the current version.
• Database copies: a secret stored encrypted on the connection may need to be entered again after the database is copied to another environment, like other platform-encrypted values such as the email SMTP password. A Key Vault reference is unaffected.
• The token is scoped to Key Vault only and is sent only to a Key Vault host. It is cached in memory until shortly before it expires (one per cloud) and is never logged or stored.
• With a managed identity there is no bootstrap secret to protect.

Reference format

A Key Vault reference must be a secret URI of this form:

https://<vault-name>.vault.azure.net/secrets/<secret-name>
https://<vault-name>.vault.azure.net/secrets/<secret-name>/<version>

The host may instead be a vault on a sovereign-cloud Key Vault domain: .vault.azure.cn, .vault.usgovcloudapi.net or .vault.microsoftazure.de. The URI must use https, the default port and no user name. Any other address is rejected: in the Authentication field (a value starting with https:// or http:// that is not a valid reference) and in the two PGP reference fields when you save, and again before a token is requested, because the AOS server's Key Vault token is sent to that address.