Azure Data Lake Store Not Encrypted: Risks and Remediation

Data lakes hold the messy, high-value stuff: raw event streams, customer records, financial exports, machine learning feature sets. When that data sits in an Azure Data Lake Store without encryption at rest, you are trusting that nobody, internal or external, ever gets at the underlying disks or backups in cleartext. That assumption rarely survives an audit.

The datalake_unencrypted check looks at your Azure Data Lake Store accounts and reports any that do not have encryption enabled. Below is what it actually inspects, why it should not sit on your backlog, and how to fix and prevent it.

---

What this check detects

The check inspects Azure Data Lake Store Gen1 accounts and verifies that the encryptionState property is set to Enabled. If an account reports Disabled, it is flagged.

Azure Data Lake Store Gen1 supports encryption at rest using one of two key management modes:

• Service-managed keys — Azure generates and manages the encryption keys for you. No key vault setup required.
• Customer-managed keys — You supply and manage keys in Azure Key Vault, giving you control over rotation and revocation.

Critically, encryption state on Gen1 can only be configured at account creation time. You cannot toggle it on an existing account. That single constraint is the reason this finding matters so much, because the remediation path is not a quick property update.

---

Why it matters

Encryption at rest is a baseline control, not a nice-to-have. When it is missing, several realistic risks open up.

Exposure of raw data on the storage layer

A data lake is typically the least sanitized copy of your data in the entire organization. It is where pipelines dump raw ingestion before anyone applies masking, tokenization, or column-level access policies. If that data sits unencrypted, any compromise of the underlying storage, a misconfigured backup, a snapshot copied to the wrong subscription, or insider access at the infrastructure level, hands an attacker readable content directly.

Compliance failures

Encryption at rest is an explicit requirement in most regimes you are likely subject to. PCI DSS, HIPAA, SOC 2, ISO 27001, and GDPR all expect data at rest to be protected. An unencrypted data lake holding cardholder data or PHI is a finding that auditors will not let slide, and remediation under time pressure is far more expensive than getting it right up front.

No defense in depth

Access controls and network rules are your front door. Encryption at rest is the safe behind the wall. When you rely solely on identity and network controls, a single misconfiguration, an overly broad role assignment or an open firewall rule, becomes a full data breach instead of a contained incident.

---

How to fix it

There are two practical paths depending on whether you stay on Gen1 or move to Gen2. We strongly recommend Gen2.

Option A (recommended): migrate to Data Lake Storage Gen2

Gen2 storage accounts encrypt all data at rest by default with no configuration required. Create a storage account with hierarchical namespace enabled, which is what turns a regular Blob account into a Gen2 data lake.

az storage account create \
  --name mydatalakegen2 \
  --resource-group my-rg \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --hierarchical-namespace true \
  --encryption-services blob

Then migrate your data. For one-time bulk copies, azcopy handles Gen1 to Gen2 transfers well:

azcopy copy \
  "adl://myoldgen1.azuredatalakestore.net/data/" \
  "https://mydatalakegen2.dfs.core.windows.net/data/" \
  --recursive=true

Option B: recreate the Gen1 account with encryption enabled

If you must stay on Gen1 for now, the only way to get encryption is to create a new account with it enabled and migrate data into it.

Create a new Gen1 account with service-managed encryption:

az dls account create \
  --account mynewdatalake \
  --resource-group my-rg \
  --location eastus2 \
  --encryption-type ServiceManaged

To verify encryption state on any existing account:

az dls account show \
  --account mynewdatalake \
  --resource-group my-rg \
  --query "encryptionState"

A healthy result returns "Enabled".

Using customer-managed keys

If your compliance posture requires control over key lifecycle, point encryption at a Key Vault key during creation. This requires a Key Vault, a key, and the right access policy granting the Data Lake Store service access to the key.

# Create the key
az keyvault key create \
  --vault-name my-datalake-kv \
  --name datalake-cmk \
  --kind RSA \
  --size 2048

Then reference it when creating the account through ARM or Terraform, since the CLI flag set for full CMK wiring is limited. See the IaC example below.

---

How to prevent it from happening again

Manual fixes do not scale. The durable answer is to make unencrypted data lakes impossible to deploy in the first place.

Define it in infrastructure as code

If your data lakes are created through Terraform, set encryption explicitly and review it in code. For a Gen2 account, encryption is on by default, which is one more reason to prefer it.

resource "azurerm_storage_account" "datalake" {
  name                     = "mydatalakegen2"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
  account_kind             = "StorageV2"
  is_hns_enabled           = true

  # Encryption at rest is enabled by default on Gen2.
  # Add a customer-managed key block if required by policy.
}

For a legacy Gen1 account in Terraform, the encryption type is required up front:

resource "azurerm_data_lake_store" "dls" {
  name                = "mylegacydatalake"
  resource_group_name = azurerm_resource_group.rg.name
  location            = "eastus2"
  encryption_state    = "Enabled"
  encryption_type     = "ServiceManaged"
}

Enforce it with Azure Policy

Azure Policy can deny the creation of resources that do not meet your standard. Assign a policy that audits or denies Data Lake Store accounts without encryption, scoped at the management group level so it applies across every subscription.

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.DataLakeStore/accounts"
      },
      {
        "field": "Microsoft.DataLakeStore/accounts/encryptionState",
        "notEquals": "Enabled"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Add a CI/CD gate

Catch the problem before it reaches Azure. Run a static analysis tool such as Checkov or tfsec against your Terraform in the pipeline, and fail the build on any plan that creates an unencrypted store. Pair that with continuous scanning in Lensix so drift introduced outside your pipeline, manual portal changes, for example, still gets caught.

---

Best practices

• Prefer Gen2 over Gen1. Gen1 is on its way out and Gen2 gives you encryption by default, lower cost, and better integration with the rest of the Azure analytics stack.
• Layer your controls. Encryption at rest is one layer. Combine it with private endpoints, network firewall rules, RBAC scoped to least privilege, and ACLs on the data itself.
• Use customer-managed keys for regulated data. When you need to prove control over key rotation and revocation, CMK in Key Vault gives auditors a clear answer. Enable key rotation policies so you are not managing it by hand.
• Encrypt in transit too. At-rest encryption does nothing for data moving across the network. Enforce HTTPS and TLS 1.2 or higher on every endpoint that touches the lake.
• Scan continuously, not just at deploy. Configuration drifts. A control that was correct at deployment can be weakened by a later change. Continuous monitoring closes that gap.

The fix here is rarely a one-line command because Gen1 encryption is immutable, but that is exactly why it deserves attention now rather than during your next audit. Plan the migration to Gen2, bake encryption into your IaC, and gate it in your pipeline so the finding never comes back.