# Azure SQL Database TDE Not Enabled > Rule RC-1330 fires when an Azure SQL database's tde_enabled metadata, derived from the live transparent-data-encryption sub-resource, is exactly "false". Data files, backups, and transaction logs are then unencrypted at rest. Unlike disk encryption elsewhere, the fix is an in-place toggle; ZopNight abstains whenever the flag is missing. Source: https://zop.dev/integrations/azure/recommendations/azure-sql-database-tde-not-enabled Updated: 2026-08-19 --- ## What sits unencrypted when TDE is off Transparent Data Encryption protects three things: the database files themselves, every backup taken from them, and the transaction logs. All three are exactly what leaves your control most often: backups get copied to other regions, exported for restores, and occasionally left in storage accounts with looser access than the database. A stolen or mis-shared backup of a TDE-off database is readable as-is. On a TDE-on database the same file is useless without the key. High severity here reflects that the backup surface, not the live database endpoint, is the realistic exposure. ## A finding that usually means someone turned it off Azure enables TDE by default on new databases, so a database reporting `tde_enabled: "false"` is rarely an oversight of creation. More often it is an old database migrated from elsewhere, or a deliberate disable that never got reverted (sometimes done to speed up a bulk load). Either way the state is worth an explanation, and the rule surfaces it so someone has to give one. ## The signal is the ARG sub-resource, not a tag The Azure discoverer reads the per-database transparent-data-encryption sub-resource through Azure Resource Graph and writes the state into metadata as `tde_enabled`. RC-1330 fires only on the explicit string `"false"` and abstains when the key is absent: provider evidence or nothing. A previous revision of this rule looked for the value in customer tags, where no producer ever wrote it, and was structurally dead; the metadata gate is what made it a live check. Discovery runs entirely under the built-in **Reader** role. ## Verify a database from the CLI ```bash az sql db tde show \ --resource-group --server --database \ --query status ``` `Disabled` confirms the finding; `Enabled` means encryption is active. ## Remediation is genuinely easy here Unlike unencrypted disks, which need snapshot-copy-replace surgery, TDE is an in-place toggle. Enable it in the portal or with `az sql db tde set --status Enabled`, and Azure encrypts existing data in the background with no downtime. Choose service-managed keys unless your compliance program requires customer-managed keys in Key Vault. The recommendation carries no dollar saving; the value is closing the backup-exposure gap and the audit finding with a change that takes minutes.