Azure Cache for Redis Security Best Practices

Azure Cache for Redis is a data store, not just a cache. Session data, access tokens, user preferences, and sometimes fragments of sensitive application data all live in Redis. A Redis instance with weak network controls or unrotated access keys is a meaningful attack surface. The default configuration of a new Azure Cache for Redis instance is more permissive than most production environments should accept.

This guide covers the security controls that matter: network isolation, TLS enforcement, authentication, encryption at rest, and monitoring.

Network isolation: the most important control

The most impactful Redis security control is keeping it off the public internet entirely. An Azure Cache for Redis instance on the Standard or Premium tier can be deployed with a virtual network (VNet) injected directly into a subnet, or with a Private Endpoint that puts it on your private network.

Private Endpoint (recommended for all tiers). A Private Endpoint assigns your Redis cache a private IP address inside your VNet. All traffic to the cache goes over the private network. The public endpoint is disabled. This removes the cache from public internet exposure entirely. Use Private Endpoints for all production Redis caches.

For the Private Endpoint to work, configure a Private DNS Zone (privatelink.redis.cache.windows.net) linked to the VNet. Applications in the VNet resolve the cache hostname to the private IP rather than the public one.

VNet injection (Premium tier only). Premium tier supports deploying the Redis cache directly into a subnet of your VNet. This is an older model; Private Endpoints are generally preferred for new deployments because they are available across tiers and integrate cleanly with hub-and-spoke DNS architecture.

IP firewall rules as a fallback. If Private Endpoints are not yet in place, configure IP allowlist rules to restrict access to specific IP ranges. This is not a substitute for Private Endpoints: it relies on correctly maintained IP lists and still leaves the cache reachable over the public internet. Treat it as a temporary control while migrating to Private Endpoints.

Once network isolation is in place, disable non-SSL access.

Enforce TLS: disable non-SSL access

Azure Cache for Redis is accessible over port 6379 (non-SSL) and port 6380 (SSL/TLS). Non-SSL access is disabled by default for new caches. If it has been enabled for any reason (legacy application compatibility, testing), disable it:

In the Azure Portal, navigate to your Redis cache > Advanced settings > Require SSL: set to Yes.

Enforce TLS 1.2 as the minimum version. TLS 1.0 and 1.1 have known vulnerabilities and should not be in use. Set the minimum TLS version under Advanced settings > Minimum TLS Version.

All clients should connect using the SSL port (6380) and with ssl=True in the connection string. Connections on port 6379 without SSL should fail, confirming the enforcement is working.

Replace access keys with Microsoft Entra ID authentication

Azure Cache for Redis access keys are shared secrets that grant full access to the cache. They do not have expiry dates by default. They are often embedded in application configuration files or environment variables, where they accumulate and are rarely rotated.

Microsoft Entra ID authentication (available on Redis 6, Premium tier and above) replaces access key authentication with OAuth 2.0 tokens issued by Entra ID. Applications authenticate using a managed identity, which gets a short-lived token automatically. No password to store, no manual rotation, automatic credential refresh.

Enable Entra ID authentication in the Azure Portal under Authentication. Create a Redis user assignment for the managed identity:

az redis access-policy-assignment create \
  --name my-cache \
  --resource-group my-rg \
  --policy "Data Owner" \
  --object-id {managedIdentityObjectId} \
  --policy-assignment-name my-app-access

Update the application connection string to remove the password and use the managed identity credential:

var options = new ConfigurationOptions
{
    EndPoints = { "my-cache.redis.cache.windows.net:6380" },
    Ssl = true,
    AbortOnConnectFail = false,
};
await options.ConfigureForAzureWithTokenCredentialAsync(new DefaultAzureCredential());
var redis = ConnectionMultiplexer.Connect(options);

If Entra ID authentication is not yet possible (older tier or Redis version), implement access key rotation: regenerate keys on a schedule (monthly or quarterly), update application configuration, and ensure no application is using the old key before disabling it. Azure Key Vault with automatic rotation can manage this lifecycle.

Encryption at rest

Azure Cache for Redis encrypts data at rest by default using Microsoft-managed keys. For environments requiring customer-managed keys (CMK), this is available on the Enterprise and Enterprise Flash tiers. With CMK, you provide the encryption key via Azure Key Vault, and you control the key lifecycle including rotation and revocation.

For most workloads on Basic, Standard, and Premium tiers, Microsoft-managed encryption at rest is adequate. The requirement for CMK typically comes from compliance frameworks (PCI DSS, HIPAA, FCA) that mandate customer control over encryption keys for specific data categories.

Monitor access and detect anomalies

Enable diagnostics and route logs to Log Analytics. The relevant log categories for security monitoring are:

Connection Events: Each connection to the Redis cache is logged. Unexpected source IPs, connections outside business hours, or a sudden spike in connection count are signals worth alerting on.

Authentication Events: Failed authentication attempts. Multiple failures from the same source indicate a brute-force attempt or a misconfigured application.

Access Key Usage: If you are using access keys rather than Entra ID, monitor which applications are using which keys. An access key appearing from an unexpected source (a public IP, an IP outside your VNet) is a signal that the key has been exposed.

Set up a Microsoft Defender for Cloud alert policy for Azure Cache for Redis. Defender monitors for unusual access patterns, known malicious IP connections, and potential data exfiltration indicators.

For operational visibility, expose Redis performance metrics (server load, memory usage, connected clients, cache hits/misses) in your observability platform alongside the security signals. A spike in connected clients alongside failed authentication events tells a different story than either signal alone.

Disable non-production access keys in production

A common misconfiguration is deploying the same Redis connection string across development, staging, and production environments. If the development environment is compromised or a developer inadvertently logs the connection string, the production cache is exposed.

Use separate Redis instances per environment with separate access keys (or separate managed identities). This is not redundant: the isolation means a credential exposure in a lower environment does not affect production.

If infrastructure constraints require sharing a Redis instance across environments, use separate ACL users (available in Redis 6) with restricted permissions per environment: the dev environment's user can read and write only the key prefixes allocated to dev, not to staging or production.

Where Critical Cloud comes in

Redis security misconfigurations are common and consequential. They are also the type of issue that does not appear in a security review until after something goes wrong. We configure and operate Azure Cache for Redis as part of the managed platform for regulated and technology-led businesses, with network isolation, Entra ID authentication, and access monitoring in place from the start. As the world's first Powered by Datadog accredited partner, we monitor Redis connection events, authentication failures, and unusual access patterns as live security signals. See how Critical Support works.