Secrets, Keys & Certificates
Azure Key Vault is the architect's answer to 'where do we put the secrets?' Learn when to use Key Vault, Managed HSM, and certificate management — and when managed identities make secrets unnecessary.
Why secrets management design matters
Secrets are like car keys — you need them to go anywhere, but leaving them on the dashboard is asking for trouble.
Azure Key Vault is a secure vault (literally) for storing three types of sensitive data: secrets (passwords, connection strings, API keys), keys (encryption keys for protecting data), and certificates (TLS/SSL certificates for secure communication).
The architect’s job is designing WHERE secrets live, WHO can access them, and HOW to avoid needing them in the first place (managed identities).
Key Vault design patterns
Vault topology
| Pattern | Description | Best For |
|---|---|---|
| Per application | Each app gets its own vault | Strong isolation between apps, clear ownership |
| Per environment | Dev, staging, production vaults | Prevent dev secrets leaking to production |
| Per region | Vault in each deployment region | Low-latency access, regional compliance |
| Combined | App + environment + region | Enterprise standard: kv-appname-prod-aue |
🏦 Elena’s design: FinSecure Bank uses the combined pattern:
kv-riskengine-prod-westeurope— production risk engine secrets in EUkv-riskengine-dev-westeurope— dev environment (different access policies)kv-shared-prod-westeurope— shared certificates (TLS wildcards)
Design principle: Don’t put all secrets in one vault. Key Vault has throttling limits (several thousand transactions per 10 seconds). Multiple apps hitting one vault can cause 429 errors. Separate vaults per app also reduce blast radius if a vault is compromised.
Key Vault access models
| Factor | Vault Access Policy (legacy) | Azure RBAC (recommended) |
|---|---|---|
| Granularity | All-or-nothing per object type (secrets, keys, certs) | Per-operation (read, write, delete, backup, etc.) |
| Scope | Vault level only | Vault, secret, key, or certificate level |
| Integration | Standalone policy per vault | Unified with Azure RBAC — same portal, same tools |
| Conditional Access | Not supported | Supported — add context-aware policies |
| Audit | Separate audit mechanism | Standard Azure RBAC audit logs |
| Best for | Legacy deployments — migrate away | All new deployments |
Exam tip: Always recommend Azure RBAC for Key Vault
Microsoft recommends Azure RBAC over vault access policies for all new deployments. If an exam scenario doesn’t specify a constraint, recommend RBAC. Key built-in roles:
- Key Vault Administrator: Full management of all vault content
- Key Vault Secrets Officer: Manage secrets only
- Key Vault Secrets User: Read secrets only (ideal for applications)
- Key Vault Crypto Officer: Manage keys
- Key Vault Certificates Officer: Manage certificates
Key Vault vs Managed HSM
For encryption key management, the choice depends on your compliance requirements:
| Factor | Key Vault Standard | Key Vault Premium | Managed HSM |
|---|---|---|---|
| Key protection | Software-protected | HSM-protected (shared HSM pool) | Dedicated FIPS 140-2 Level 3 HSM |
| Key types | RSA, EC | RSA, EC (HSM-backed) | RSA, EC, AES (full HSM control) |
| Compliance | General use | Most regulations | FIPS 140-2 Level 3 — for orgs requiring dedicated HSM hardware |
| Performance | Good | Good | High — dedicated HSM capacity |
| Cost | Lowest | Medium | Highest — dedicated hardware |
| Best for | Dev, non-regulated apps | Most production workloads | Financial services, government, high-security |
🏦 Elena’s decision: FinSecure Bank uses Managed HSM for customer encryption keys (their internal security policy requires FIPS 140-2 Level 3 dedicated hardware) and Key Vault Premium for application secrets and TLS certificates (HSM-protected but shared pool is fine for secrets).
Certificate management design
Certificate sources
| Source | Description | Auto-Renewal |
|---|---|---|
| Key Vault generated | Key Vault acts as CA client, requests from integrated CAs | Yes — automatic before expiry |
| Self-signed (KV generated) | Key Vault creates self-signed certs | Yes — automatic rotation |
| Imported | Upload existing PFX/PEM certificates | No — manual replacement |
| App Service Managed Certificates | Free TLS certs for App Service custom domains | Yes — auto-renewed by Azure |
🚀 Marcus’s strategy: NovaSaaS uses:
- App Service Managed Certificates for customer-facing domains (free, auto-renewed)
- Key Vault integrated certificates (DigiCert CA) for API mutual TLS (auto-renewed, stored centrally)
- Self-signed for dev/test only (never production)
Design decision: Certificate rotation and zero-downtime
When designing certificate management, plan for rotation:
- Key Vault + App Service integration: App Service can reference a Key Vault certificate. When the cert is renewed in Key Vault, App Service picks it up automatically (within 24 hours).
- Key Vault + Application Gateway: Similar integration — cert updates propagate automatically.
- Key Vault + custom apps: Use Key Vault SDK with certificate version “latest” to always get the current cert on app restart.
Anti-pattern: Don’t hard-code certificate thumbprints in application config. When the cert rotates, your app breaks.
The secret elimination hierarchy
Before adding a secret to Key Vault, ask: can I eliminate it entirely?
| Priority | Approach | Example |
|---|---|---|
| 1 | Managed identity | App Service → Storage (no connection string needed) |
| 2 | Workload identity federation | GitHub Actions → Azure (no stored secret) |
| 3 | Certificate-based auth | Service principal with certificate instead of secret |
| 4 | Key Vault secret | Third-party API keys that can’t use managed identity |
| 5 | Connection string | Last resort — stored in Key Vault, referenced by app |
🏛️ David’s rule for government clients: “If you’re putting a secret in Key Vault, you should first explain why a managed identity won’t work. Every secret is an operational liability — it can expire, leak, or be misconfigured. The fewer secrets you manage, the more secure and reliable your architecture.”
Knowledge check
🏦 FinSecure Bank needs to store encryption keys for customer data. Their compliance framework (PCI DSS) requires FIPS 140-2 Level 3 hardware protection. They also need to store TLS certificates and application secrets. Which combination should Elena recommend?
🚀 Marcus's team is building a new microservice that needs to access Azure Cosmos DB and Azure Storage. What should Marcus recommend as the FIRST approach for authentication?
🎬 Video coming soon
Next up: Individual access is designed — now let’s think bigger. How do you govern hundreds of subscriptions? — Governance at Scale.