Azure Key Vault: Secrets and Certificate Management for Small Businesses in Berlin

Hardcoded credentials are one of the most common and preventable causes of cloud security incidents. A database password embedded in a WordPress configuration file, an API key stored in a shared password manager, an SSL certificate that expired because no one tracked the renewal date — these are the operational failures that Defender for Cloud and security auditors flag repeatedly. Azure Key Vault is Microsoft’s managed secrets, keys, and certificate service that eliminates all three problems with a single, RBAC-governed, HSM-backed service that integrates natively with every Azure workload.

This guide explains what Key Vault manages, how RBAC and managed identities provide passwordless access, how certificate lifecycle management works, and how Berlin businesses can migrate hardcoded credentials to Key Vault.

Three Object Types: Keys, Secrets, Certificates

Azure Key Vault manages three distinct object types, each with its own access control plane and versioning model:

Keys

Cryptographic keys used for encryption, decryption, signing, and key wrapping. Key Vault supports RSA keys (2048, 3072, 4096-bit) and elliptic curve keys (P-256, P-384, P-521). In the Standard tier, keys are software-protected. In the Premium tier, keys are generated and stored in FIPS 140-2 Level 2 validated HSMs (Hardware Security Modules) — the private key material never leaves the HSM boundary.

Azure Disk Encryption, Azure Storage encryption, and Azure SQL Transparent Data Encryption can all use Key Vault customer-managed keys (CMK), giving you control over the encryption key lifecycle including rotation and revocation — a requirement for GDPR data erasure scenarios where key deletion renders encrypted data unreadable.

Secrets

Arbitrary string values: database connection strings, API keys, SMTP credentials, SAS tokens, application passwords. Secrets are versioned — when you rotate a secret, the new version is created while the old version remains accessible until explicitly disabled. Applications reference secrets by URI, and can pin to a specific version or always retrieve the latest version. Maximum secret size is 25 KB.

Replacing hardcoded credentials with Key Vault secret references eliminates the most common configuration-file exposure risk: a developer accidentally commits a secrets-containing config file to a public GitHub repository. With Key Vault, configuration files contain only the Key Vault URI — no credential value.

Certificates

Key Vault manages the complete certificate lifecycle: creation, storage, auto-renewal, and delivery to consuming applications. Certificates can be self-signed (for internal use) or issued by integrated CAs — DigiCert and GlobalSign are natively integrated partners. Let’s Encrypt certificates can be managed via custom CA policies.

Key Vault monitors certificate expiry and sends expiry notifications at configurable thresholds (typically 30 and 7 days before expiry). With auto-renewal configured via an integrated CA, certificates renew automatically before the expiry window — eliminating the “certificate expired on a Sunday evening” incident that affects a surprising number of Berlin business websites each year.

Access Control: RBAC vs Legacy Access Policies

Key Vault supports two access models. The current recommended model is Azure RBAC using built-in roles:

Role	Permissions	Typical Assignment
Key Vault Administrator	Full control: create/delete vault objects, manage access policies	Platform engineering team
Key Vault Secrets Officer	Read, write, delete secrets; cannot manage keys or certificates	DevOps pipeline service principals
Key Vault Certificates Officer	Full certificate management; cannot read secret values	Certificate management team
Key Vault Crypto Officer	Full key management; cannot read secrets or certificates	Encryption key management team
Key Vault Secrets User	Read secret values only; cannot list, create, or delete	Application managed identities
Key Vault Reader	Read metadata only; cannot read secret values	Auditors, monitoring systems

The legacy access policies model is being deprecated in favour of RBAC. If you are creating a new Key Vault, select the RBAC permission model at creation time. RBAC provides standard Azure role management with Entra ID PIM integration, enabling just-in-time privileged access to vault administration — the same model used across all other Azure resources.

Managed Identities: Passwordless Application Access

The most operationally clean way for Azure workloads to access Key Vault is through managed identities — Entra ID service principals whose credentials are managed entirely by Azure. There are no client secrets to rotate, no service account passwords to manage, and no credentials to accidentally expose in application logs.

The pattern for a WordPress application running on an Azure App Service accessing Key Vault:

1. Enable system-assigned managed identity on the App Service: Settings → Identity → Status: On
2. In Key Vault, assign the Key Vault Secrets User role to the App Service’s managed identity object ID
3. In the WordPress application configuration, replace the hardcoded DB_PASSWORD value with the Key Vault secret URI using the App Service Key Vault reference syntax: @Microsoft.KeyVault(SecretUri=https://your-vault.vault.azure.net/secrets/wp-db-password/)
4. App Service automatically fetches the secret value at runtime using the managed identity — no credential in any configuration file, environment variable export, or code repository

The same pattern applies to Azure Functions, Azure Container Apps, Azure Virtual Machines, and any other Azure workload that supports managed identities — which is every compute service Microsoft has released since 2017.

Soft-Delete and Purge Protection

Key Vault’s soft-delete feature retains deleted vault objects for a configurable retention period (7–90 days, default 90) in a recoverable state. Deleting a secret does not immediately destroy it — it moves to a “deleted” state from which it can be recovered within the retention window. This protects against accidental deletion and supports GDPR data recovery obligations.

Purge protection, when enabled, prevents any user — including vault administrators and subscription owners — from permanently purging a deleted vault object until the retention period has elapsed. Enable purge protection on vaults that contain production keys used for storage encryption: without it, an attacker with Key Vault Administrator access could purge a key, rendering all data encrypted with that key permanently unreadable.

Diagnostic Logging and Sentinel Integration

Key Vault diagnostic settings can stream all vault access logs — every GET, SET, and DELETE operation on any vault object, including the identity of the requestor and the object accessed — to a Log Analytics workspace. With Microsoft Sentinel connected to the same workspace, Key Vault audit logs become SIEM-visible.

Useful Sentinel analytics rules for Key Vault:

• Alert when a secret is accessed by an identity that has never accessed it before
• Alert when Key Vault access policies or RBAC assignments are modified outside a change window
• Alert on high-volume secret list operations (a characteristic of credential-harvesting attacks)
• Alert when purge protection is disabled on a vault

This logging posture directly supports Microsoft Secure Score improvement: enabling Key Vault diagnostic logs and configuring expiry policies for all secrets and keys are scored improvement actions in the Azure Security Benchmark that feeds the Secure Score calculation. These same controls are improvement actions in Microsoft Purview Compliance Manager under the ISO 27001 and GDPR regulatory templates.

Private Endpoint: Eliminating Public Network Exposure

By default, Key Vault is accessible over the public internet, protected only by Entra ID authentication and RBAC. For production environments, configure a Private Endpoint: a private IP address in your Azure VNet that maps to the Key Vault instance. Once a private endpoint is configured, you can disable all public network access — the vault is reachable only from within the VNet or via VPN/ExpressRoute.

For Berlin businesses with Azure-hosted workloads, enabling private endpoint and disabling public access is a security best practice that eliminates the vault from the public attack surface entirely.

Cost

• Standard tier (software-protected keys): ~€0.03 per 10,000 operations; ~€3 per certificate per month for managed certificates
• Premium tier (HSM-protected keys): ~€1.02 per HSM-protected key per month plus operations charges
• Azure Managed HSM (dedicated single-tenant HSM cluster): ~€3,500/month — appropriate for regulated industries requiring FIPS 140-2 Level 3 or eIDAS compliance

For a Berlin small business running a WordPress site, a few Azure resources, and certificate management for 2–3 domains, Standard tier Key Vault costs are typically under €10/month — a negligible operational expense relative to the security and compliance value delivered.

Migration Guide: From Hardcoded Credentials to Key Vault

1. Create a Key Vault in the Azure portal: region Germany West Central, permission model Azure role-based access control, enable soft-delete and purge protection
2. Assign yourself the Key Vault Secrets Officer role
3. Add each hardcoded credential as a Key Vault secret: Secrets → Generate/Import → Manual → Name (e.g., “wp-db-password”), Value (the credential), set expiry date (90 days for passwords, 1 year for API keys)
4. Enable Managed Identity on each Azure workload that consumes the secrets
5. Assign the Key Vault Secrets User role to each workload’s managed identity
6. Update application configuration to reference secrets via Key Vault URI (syntax varies by compute service — App Service Key Vault References, Azure Functions Key Vault references, or the Azure SDK DefaultAzureCredential pattern)
7. Enable diagnostic settings: Diagnostic settings → Add → AuditEvent → send to your Log Analytics workspace
8. Set up expiry alerts: Events → Add event subscription → filter for Microsoft.KeyVault.CertificateNearExpiry and SecretNearExpiry events → route to email or Teams webhook

After migration, no credential value exists outside the Key Vault. Rotation is operationally simple: create a new secret version in the vault, update the application reference to the new version (or use the version-agnostic URI for automatic latest-version retrieval), and disable the old version. Zero application downtime, zero credential exposure in configuration files, and a full audit trail of every access operation in the diagnostic log.