Azure Key Vault Keys, Secrets, Certificates

August 14, 2026 Khimananda Oli 7 min read Database

By Khimananda Oli | Last reviewed: August 2026

Managing sensitive configuration securely is the foundation of any compliant cloud architecture. Azure Key Vault Keys, Secrets, and Certificates provide a centralized, HSM-backed repository that eliminates hardcoded credentials and automates cryptographic lifecycle management. This guide covers the practical implementation patterns required to integrate these three distinct object types into modern DevOps workflows without introducing latency or permission errors.

Quick answer: Azure Key Vault Keys, Secrets, and Certificates are distinct managed objects: Keys handle encryption and signing via HSMs, Secrets store API keys and connection strings with versioning, and Certificates manage TLS/SSL lifecycles including auto-renewal. All three require explicit RBAC policies and should be accessed via Managed Identity in production.

Core architecture of Azure Key Vault Keys, Secrets, and Certificates with integrated service access patterns

What is the difference between Azure Key Vault Keys, Secrets, and Certificates?

A common mistake I see during audits is treating Key Vault as a generic key-value store. While they share an API surface, Keys, Secrets, and Certificates serve fundamentally different cryptographic and operational purposes. Understanding these boundaries prevents security misconfigurations and performance bottlenecks.

Keys: Cryptographic Operations

Keys are cryptographic primitives used for encryption, decryption, signing, and verification. They can be software-protected or HSM-protected (FIPS 140-2 Level 2 validated). You never export private keys from an HSM-backed vault; operations occur inside the boundary. Use cases include TDE for Azure SQL, disk encryption for VMs, and envelope encryption for application data. In 2026, RSA-OAEP-256 and EC P-256/P-384 remain the recommended algorithms for new deployments.

Secrets: Sensitive Configuration Values

Secrets are arbitrary byte arrays (up to 25KB) representing passwords, connection strings, API tokens, or license keys. Unlike Keys, Secrets have no cryptographic functionality—they are simply stored and retrieved. Each Secret supports unlimited versioning, enabling safe rotation without downtime. Content-Type metadata helps applications parse values correctly (e.g., application/json vs text/plain). For teams managing database credentials across environments, integrating with PostgreSQL administration essentials ensures secrets map cleanly to role-based access models.

Certificates: Managed X.509 Lifecycle

Certificates combine a public certificate, private key, and optional chain into a single managed object. Key Vault can issue certificates via integrated CAs (DigiCert, GlobalSign) or import existing ones. The critical differentiator is automated renewal: you define an issuance policy, and Key Vault renews the cert before expiry, updating bound App Services or AKS clusters automatically. This eliminates the #1 cause of TLS outages I encounter: expired certificates due to manual tracking.

Feature	Keys	Secrets	Certificates
Primary Use	Encryption, Signing, Wrapping	Passwords, Tokens, Config	TLS/mTLS, Code Signing
HSM Support	Yes (Standard & Premium)	No (Software only)	Yes (Premium tier)
Max Size	N/A (Key type dependent)	25 KB	~25 KB (cert + key)
Auto-Rotation	Via Rotation Policy	Via Rotation Policy	Built-in Issuance Policy
Export Private Material	No (HSM), Yes (Software)	Yes (Always)	Yes (If marked exportable)

How do you configure RBAC for Azure Key Vault Keys, Secrets, and Certificates?

The legacy "Access Policies" model is deprecated. In 2026, you must use Azure RBAC for all permission management. This aligns Key Vault with your broader identity governance and enables conditional access, PIM, and auditability at scale.

Assign Least-Privilege Roles

Never assign Key Vault Administrator to applications. Use granular built-in roles:

Key Vault Secrets User: Read-only access to secret values. Assign to app identities.
Key Vault Secrets Officer: Create/update/delete secrets (no read). Assign to CI/CD pipelines.
Key Vault Crypto Service Encryption User: Perform crypto operations with keys. Assign to Azure SQL/Storage.
Key Vault Certificate User: Read certificates. Assign to ingress controllers.

Bind Permissions to Managed Identities

Service principals with client secrets are a liability. Always use system-assigned or user-assigned managed identities. When deploying to AKS, leverage workload identity federation to avoid long-lived credentials entirely—a pattern detailed in Kubernetes secrets management done right.

# Assign Secrets User role to an App Service managed identity
az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee-object-id $APP_SERVICE_MI_OBJECT_ID \
  --scope "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vault-name}" \
  --assignee-principal-type ServicePrincipal

Enable Diagnostic Logging for Compliance

RBAC controls access, but diagnostics prove compliance. Send AuditEvent logs to Log Analytics with a retention policy matching your regulatory requirements (SOC 2 typically requires 12 months). Filter on OperationName to detect unauthorized reads or failed authentication attempts. This evidence collection is non-negotiable for ISO 27001 audits.

RBAC decision flow for Azure Key Vault Keys, Secrets, and Certificates data plane access

How do you implement automatic rotation for Azure Key Vault Secrets and Keys?

Manual rotation is a compliance failure waiting to happen. Azure Key Vault now supports native rotation policies for both Secrets and Keys, eliminating external cron jobs or Logic Apps for most scenarios.

Configure Secret Rotation Policies

Define how often a secret should rotate and whether Key Vault generates the new value or triggers an external function. For database passwords, pair this with MySQL performance tuning guide practices to ensure credential changes don’t disrupt connection pools.

# Set auto-rotation policy: rotate every 30 days, generate new random password
az keyvault secret set-attributes \
  --vault-name my-vault \
  --name db-password \
  --enable-auto-rotate true \
  --rotation-period P30D \
  --expiry-period P90D

Key Rotation for Envelope Encryption

For TDE or storage encryption, rotate backing keys annually while maintaining previous versions for decryption. Applications using envelope encryption must fetch the latest key version dynamically—never cache key identifiers indefinitely. Monitor rotation success via RotationEvent diagnostics; failures here silently stall compliance.

Certificate Auto-Renewal Best Practices

Certificate renewal differs from secret rotation. Configure issuance policies with a renewal threshold (e.g., 30 days before expiry). Test renewal in staging first—CA validation failures are common with DNS challenges. Bind renewed certs to App Gateway or AKS via references, not exports, to maintain the auto-update chain.

How do you integrate Azure Key Vault with AKS and App Service?

Direct API calls from pods or apps introduce latency and complexity. Use platform-native integrations that inject secrets as files or environment variables securely.

AKS: Secrets Store CSI Driver + Workload Identity

The Secrets Store CSI Driver mounts Key Vault objects as volumes. Combined with Azure Workload Identity, pods authenticate without node-level permissions. This is the gold standard for Kubernetes on Azure in 2026.

Install the CSI driver via AKS add-on or Helm.
Create a SecretProviderClass referencing vault objects.
Annotate pod specs with workload identity client ID.
Mount volume; secrets appear as files at runtime.

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    clientID: "${WORKLOAD_IDENTITY_CLIENT_ID}"
    keyvaultName: "prod-keyvault"
    objects: |
      array:
        - |
          objectName: app-db-secret
          objectType: secret
          objectVersion: ""
        - |
          objectName: tls-cert
          objectType: cert
          objectVersion: ""

App Service: Key Vault References

Use @Microsoft.KeyVault(SecretUri=...) syntax in App Settings. The platform resolves values at runtime using the app’s managed identity. No code changes needed. Enable soft-delete and purge protection on the vault to prevent accidental reference breakage during deployments.

Direct API versus native integration trade-offs for Azure Key Vault Keys, Secrets, and Certificates

Secure Your Azure Key Vault Keys, Secrets, and Certificates Today

Implementing Azure Key Vault Keys, Secrets, and Certificates correctly transforms your security posture from reactive patching to proactive governance. Start by migrating legacy access policies to RBAC, enable diagnostic logging immediately, and adopt CSI/native integrations over direct SDK calls. These steps alone resolve the majority of audit findings and outage root causes I see in production environments. If your team needs help designing a compliant vault architecture or integrating with existing AKS/App Service workloads, reach out to discuss your specific requirements.

Frequently Asked Questions

Keys are cryptographic assets for encryption and signing. Secrets store arbitrary text like connection strings or API tokens. Certificates manage X.509 credentials with automated lifecycle policies. Each type uses distinct APIs and access controls within the same vault instance for organized security management.

Run az keyvault secret set with the vault name and secret value parameters. The command returns metadata including the version ID needed for retrieval. Always use service principal authentication rather than user credentials in automation scripts to ensure consistent non-interactive access during deployments.

Yes, configure auto-renewal policies when creating certificates. Key Vault monitors expiry dates and requests new certificates from integrated CAs like DigiCert or GlobalSign. Set notification thresholds to trigger alerts before renewal attempts occur, ensuring continuous availability without manual intervention for TLS certificate lifecycle management.

Standard tier charges per 10,000 transactions plus HSM-backed key fees if used. Premium tier includes dedicated HSM capacity at higher base rates. Secret and certificate operations cost significantly less than cryptographic key operations. Monitor transaction volumes via metrics to avoid unexpected billing spikes in production environments.

Assign system-assigned or user-assigned managed identities to Azure resources. Grant least-privilege RBAC roles or access policies on the vault. Applications authenticate via IMDS endpoint without storing credentials. This eliminates secret sprawl and ensures only authorized workloads retrieve sensitive configuration values at runtime.

Your identity lacks required RBAC permissions on the vault resource. Assign Key Vault Secrets User or Administrator role depending on operation scope. Verify conditional access policies and network restrictions are not blocking requests. Propagation delays can take several minutes after role assignment changes.

Yes, use az keyvault certificate import with the PFX file path and password. Key Vault parses the certificate chain and private key, storing them securely. Imported certificates support the same lifecycle management features as generated ones, enabling centralized TLS asset governance across environments.

Use Key Vault references syntax in application settings pointing to secret URIs. Enable managed identity on the App Service and grant read permissions. Settings resolve at runtime without exposing values in portal or ARM templates. Cached values refresh periodically based on configured polling intervals.

Deleted objects enter a retention period preventing permanent removal. Recovery restores previous versions with original metadata intact. Purge protection adds mandatory waiting periods even for administrators. Both features guard against accidental or malicious data loss but increase storage costs during retention windows.

Use az keyvault secret backup to download encrypted blob files containing secret versions. Restore requires the same vault or compatible target vault. Backups include all versions and metadata but exclude access policies. Schedule regular backups via automation pipelines since Key Vault lacks native point-in-time recovery.

Yes, but isolate access using RBAC scopes or separate vaults per environment. Shared vaults reduce management overhead but increase blast radius during breaches. Apply principle of least privilege per application identity. Audit logs track all access patterns to detect unauthorized cross-application secret consumption.

Check regional availability zone alignment between vault and consuming services. Review throttling metrics indicating exceeded transaction limits. Enable diagnostic logging to identify slow operations or failed authentications. Consider Premium tier for HSM-backed keys requiring lower latency guarantees under high-throughput cryptographic workloads.

Yes, configure storage accounts to use Key Vault-hosted CMKs instead of Microsoft-managed keys. Create RSA or EC keys with appropriate permissions and link via storage encryption settings. Rotation policies update encryption keys automatically. Compliance frameworks often require CMKs for regulated data residency and sovereignty requirements.

Azure DevOps and GitHub Actions offer built-in tasks for secret retrieval during pipeline execution. Terraform and Bicep providers fetch values at deployment time. Kubernetes CSI drivers mount secrets as volumes. These integrations prevent credential exposure in logs while maintaining infrastructure-as-code reproducibility across environments.

Use az keyvault certificate show to inspect issuer hierarchy and expiration dates. Test TLS endpoints with openssl s_client to verify served certificates match vault contents. Configure validation hooks in deployment pipelines that reject certificates with incomplete chains or approaching expiry thresholds before production rollout occurs.