Dataverse secrets and Azure Key Vault integration

Solutions in Dataverse often need secrets — API keys for connectors, OAuth client credentials, encryption keys, database passwords. Hard-coding secrets in code is a security violation; the modern pattern uses environment variables with Azure Key Vault integration for production-grade secret management.

The historical pain. Pre-environment-variables:

• API keys hard-coded in plug-in code.
• Connection strings in configuration tables.
• Different secrets per environment, manually swapped.

Issues: secrets in source control, hard rotation, audit gaps.

Environment variables. A Dataverse-native mechanism for per-environment values:

• Definition — the variable shape, name, datatype.
• Value — per-environment value.
• Used in flows, plug-ins, Power Apps via the connection reference / environment variable system.

For non-sensitive values (URLs, thresholds), use String type. For secrets, use Secret type backed by Key Vault.

Secret-type environment variables.

• Definition specifies datatype: Secret.
• Value isn't stored directly in Dataverse; references a Key Vault secret.
• The reference includes Key Vault URL, secret name, version.

At runtime, when code needs the secret, Dataverse fetches it from Key Vault using a service principal granted Key Vault access.

Setup.

1. Azure Key Vault provisioned in your tenant.
2. Service principal for Dataverse granted get permission on the vault's secrets.
3. Secret stored in Key Vault.
4. Environment variable created in Dataverse referencing the Key Vault secret.
5. Solutions reference the environment variable, not the secret directly.

Why Key Vault.

• Centralised secret management — IT controls; not in solution.
• Rotation — change in Key Vault; no Dataverse change.
• Audit — Key Vault audits all access.
• Geographic isolation — secrets stay in Azure region.
• Compliance — easier to demonstrate proper secret handling.

Using secrets in plug-ins.

var secretValue = await GetSecretFromKeyVault("apiKey");

Plug-in's service-to-service authentication retrieves the secret on demand.

Using secrets in Power Automate.

• Reference environment variable in actions.
• Connector retrieves secret at runtime.
• Action uses without exposing in flow's visible content.

Using secrets in canvas apps. Limited support; typically secrets shouldn't flow client-side.

Solution-aware secrets. Environment variables go in solutions:

• Definition included.
• Default value optional (for sandbox / development).
• Per-environment value set during deployment.

This is the ALM pattern: solution exports with definitions; importing solution prompts for per-environment values.

Rotation strategy.

• Periodic rotation — every N months per policy.
• Compromised secret rotation — immediately on suspected breach.
• Process — new version in Key Vault → environment variable picks up new version automatically.

If the version is explicitly specified in the env var, you'd update the env var to point to new version.

Comparison with Power Platform connection references. Different concepts:

• Connection reference — abstract connector connection; bound to a real connection per environment.
• Environment variable — value (or secret) per environment.

Often combined: a connection reference for "SQL Server" uses an environment variable for "ConnectionString" secret.

Compliance considerations.

• GDPR — secrets handling included in privacy impact assessment.
• SOC 2 — secret management practices audited.
• HIPAA — extra rigour for healthcare data.
• PCI-DSS — strict secret handling.

Key Vault meets these compliance standards more easily than custom solutions.

Performance.

• Secret retrieval adds latency (call to Key Vault).
• Mitigate via:
  • Cache secret in memory for session (with appropriate TTL).
  • Single retrieval per process / per flow run.
• Don't retrieve secret per record in a loop.

Local development. When developing plug-ins locally:

• Dev environment uses non-prod Key Vault.
• Service principal has access to dev secrets only.
• No prod secrets ever in dev environment.

Common pitfalls.

• Hard-coded secrets in plug-in code. Backwards practice; rotate to environment variables.
• Secrets in solution XML. Visible in source control; rotate immediately.
• No rotation discipline. Secrets unchanged for years; compromise risk.
• Wrong Key Vault permissions. Service principal lacks access; runtime failures.
• Caching secrets too long. Rotated secret not picked up; failures after rotation.
• Mixing dev / prod Key Vaults. Dev code accidentally hits prod Key Vault; permission errors.

Migration. From hard-coded secrets to Key Vault:

1. Provision Key Vault and store secrets.
2. Create environment variables.
3. Update code to read from environment variables.
4. Deploy.
5. Remove old hard-coded values.
6. Rotate the secrets (because they may have leaked during the transition).

Strategic positioning. Secret management is foundational security. Dataverse + Key Vault gives a clean, scalable pattern that meets compliance standards. For new solutions, this pattern is the default; for legacy solutions, migrating is technical debt worth paying down. The investment is moderate; the security and compliance benefits are substantial. Solution architecture in 2026 simply doesn't include hard-coded secrets — that pattern is no longer acceptable in production.