Compliance

Encrypt Azure automation and configuration data

One capability for the secrets that hide inside your automation: make sure every Automation account variable that holds a credential, key or connection string is created as an encrypted secure asset, not a plain-text value anyone with read access can pull back.

12 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-automation-account-variables-encrypted

Encrypting automation data: the basics

What does an unencrypted Automation account variable actually expose?

Azure Automation runs the unglamorous plumbing of an estate: scheduled runbooks that patch servers, rotate keys, tag resources and tidy up storage. To do that work the runbooks need values, and those values live in Automation account variables. A variable can be created in one of two states. As an encrypted secure asset, the value is sealed with a per-account key and can never be read back, only used inside a runbook. Or as a plain-text variable, where the value is stored in the clear and anyone with read access to the account can retrieve it through the portal, the API or the CLI.

The problem is that variables are where secrets quietly accumulate. A webhook URL, an API key for a third-party service, a connection string, a service-account password: each starts life as a quick variable someone needed for a runbook, and unless they remembered to mark it encrypted, it sits there in plain text. Microsoft Defender for Cloud turns this into a single recommendation, 'Automation account variables should be encrypted', which flags every Automation account that holds at least one variable created without encryption. It is the data-protection control for the part of Azure most people forget holds secrets at all.

Most of this exposure is drift, not intent. A variable created in a hurry, a runbook ported from somewhere else, a value pasted in the portal where the encrypted toggle is easy to miss. The work is to find every plain-text variable across every Automation account, decide which ones actually hold sensitive data, recreate those as encrypted secure assets, and then assign a policy so no new plain-text secret can slip in unnoticed.

In this lesson you will learn how Azure Automation stores variables, why the encrypted-versus-plain-text choice is fixed at creation, how to find every unencrypted variable across your Automation accounts, and how to remediate the sensitive ones without breaking the runbooks that depend on them. The Controls this lesson covers section lists the Defender for Cloud recommendation in this capability, linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The variable that outlived the runbook

Automation variables are deceptively sticky. A runbook gets retired, the schedule is deleted, the team that wrote it moves on, but the plain-text variable holding its service-account password stays in the account for years, still readable, still valid, still never rotated. Secret scanners and breach post-mortems repeatedly find that the most dangerous credentials are not the ones in active use but the forgotten ones left behind in places nobody thinks to check. An Automation account variable is exactly that kind of place, which is why the encrypted-by-default discipline matters even for plumbing nobody runs any more.

Finding unencrypted variables across an Automation account

Sam is the platform lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud flags 'Automation account variables should be encrypted' on the operations Automation account, which has accumulated a dozen variables over two years of runbooks.

Rather than guess which variables are sensitive, Sam lists every variable in the account and its encryption state, so the plain-text values can be separated from the encrypted ones before anything is recreated.

List every variable in the Automation account with its encryption state. The encrypted ones are safe; the plain-text ones need review.

$ Get-AzAutomationVariable -ResourceGroupName rg-automation -AutomationAccountName aa-operations | Select-Object Name, Encrypted

Name Encrypted

---- ---------

PrimaryRegion True

SqlConnectionString False

SlackWebhookUrl False

# SqlConnectionString is a plain-text credential anyone with read access can pull back. Recreate it encrypted first.

A plain-text variable holding a connection string or key is the highest-value target. The value can be read back through the portal, the API or the CLI by anyone with read access to the account.

How Defender for Cloud decides an Automation variable is exposeddeep dive

Every Automation account variable carries an 'isEncrypted' property, set when the variable is created. When it is true, the value is stored as a secure asset: Azure Automation generates a unique key per Automation account, keeps it in a system-managed Key Vault, and uses it to encrypt the variable so it can be used inside a runbook but never read back through the portal or API. When 'isEncrypted' is false, the value is stored in the clear and any principal with read access to the account can retrieve it. The Defender for Cloud recommendation 'Automation account variables should be encrypted' flags any Automation account that holds at least one variable with 'isEncrypted' set to false.

The property is fixed at creation. There is no setting to flip an existing plain-text variable to encrypted: Azure does not let you change a variable's encryption state in place, because the value would have to be read and re-stored, defeating the point. Remediation therefore always means recreating the variable as an encrypted asset and deleting the plain-text original, which is why this control is a small but deliberate task rather than a one-click toggle.

Behind the recommendation is the Azure Policy 'Automation account variables should be encrypted' (definition 3657f5a0-770e-44a3-b44e-9431ba1e9735), which ships with an Audit effect by default and maps to Microsoft Cloud Security Benchmark control DP-4, enable data at rest encryption by default. Defender for Cloud evaluates it on a periodic cycle, so recreating a variable as encrypted clears the finding on the next assessment rather than instantly. Switching the policy to a Deny effect is what turns the control from 'we encrypted what was there' into 'no new plain-text variable can be created at all'.

What is the impact of leaving automation variables unencrypted?

The direct impact is a readable standing secret. A plain-text Automation variable holding a connection string, API key or service-account password can be retrieved by anyone with read access to the account, and unlike a runtime token it does not expire and is rarely rotated. That makes it one of the most valuable things an attacker can find after gaining even limited access: a working credential, in the clear, that often unlocks something far beyond Automation itself.

The second-order impact is blast radius. Automation runbooks frequently run with elevated rights to patch, configure and clean up across an estate, so the secrets they hold tend to be powerful ones. A leaked database connection string or service-account password is rarely scoped to one resource; it is a step toward lateral movement. Sealing the variables shrinks the standing-secret surface to nothing readable, which is the whole point of a secure asset.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA and PCI DSS, expects evidence that secrets and sensitive data at rest are encrypted, and that includes the secrets your automation depends on. PCI DSS in particular calls out stored credentials and connection strings directly. A passing 'Automation account variables should be encrypted' recommendation across every account is a cheap, specific artefact that this often-overlooked store of secrets is protected.

How do you encrypt automation variables safely?

Work the capability as one loop rather than fixing variables ad hoc. The order matters: identify which plain-text variables actually hold secrets before you recreate anything, and capture each value first, because recreating a variable means deleting the original.

1. Inventory every variable by encryption state

List every variable across every Automation account and whether it is encrypted. Treat this inventory as the source of truth, not the single Defender finding, because one account flags the recommendation regardless of how many plain-text variables it holds.

2. Separate real secrets from harmless values

Not every plain-text variable is a problem. A region name, a feature flag or a retention count carries no risk in the clear. Connection strings, API keys, webhook URLs, service-account passwords and tokens do. Decide which plain-text variables hold something an attacker could use, and prioritise those.

3. Recreate the sensitive variables as encrypted assets

Because encryption is fixed at creation, recreate each sensitive variable with the encrypted flag set and delete the plain-text original. Capture the current value first, since once encrypted it can never be read back, only used inside a runbook. For credentials that several runbooks share, consider moving them to Key Vault and referencing them instead, so they live in one managed, auditable place.

4. Ratchet it shut with Azure Policy

The built-in 'Automation account variables should be encrypted' policy ships as Audit. Assign it with a Deny effect so no new plain-text variable can be created, and the safe configuration is enforced rather than merely encouraged. Keep an audit assignment in scopes where a hard deny would be too disruptive while you clean up.

# Recreate a sensitive plain-text variable as an encrypted secure asset (PowerShell).
# Encryption is fixed at creation, so capture the value, then delete and recreate.
# az automation has no in-place toggle; the value can never be read back once encrypted.
pwsh -c '
  $rg   = "rg-automation"
  $acct = "aa-operations"
  $name = "SqlConnectionString"
  $val  = (Get-AzAutomationVariable -ResourceGroupName $rg `
             -AutomationAccountName $acct -Name $name).Value
  Remove-AzAutomationVariable -ResourceGroupName $rg `
    -AutomationAccountName $acct -Name $name -Force
  New-AzAutomationVariable -ResourceGroupName $rg `
    -AutomationAccountName $acct -Name $name -Value $val -Encrypted $true
'

# Ratchet it shut: assign the built-in policy with a Deny effect so no new
# plain-text variable can be created. Look the definition up by display name,
# never paste a guessed GUID.
pid=$(az policy definition list \
  --query "[?displayName=='Automation account variables should be encrypted'].name" -o tsv)

az policy assignment create \
  --name deny-unencrypted-automation-vars \
  --policy "$pid" \
  --params '{"effect":{"value":"Deny"}}' \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud flags 'Automation account variables should be encrypted' on one account. What does the finding tell you?

Keep learning

Go deeper on how Azure Automation stores variables and the encryption choice behind this capability.

You can now treat the secrets inside your automation as one capability rather than a single red finding: inventory every variable by encryption state, separate the real secrets from harmless values, recreate the sensitive ones as encrypted secure assets, and ratchet the estate shut with the built-in deny policy. The Controls this lesson covers section below links the recommendation in this group to its deep page and fix.

Back to the library

Encrypting automation data: the cost and risk view

A zero-Azure-cost control that closes a quiet credential-leak path nobody budgets for

This is one of the cheapest controls in the catalogue to satisfy. Marking an Automation account variable as encrypted costs nothing in Azure spend: there is no premium tier, no Key Vault charge and no per-secret fee, because the encryption key is managed inside the Automation account itself. The entire cost is engineering time to find the plain-text variables and recreate the sensitive ones.

Frame the finding as a credential-exposure line on the risk register rather than a compliance checkbox. An Automation account whose variables hold a production database connection string in plain text carries a far higher expected loss than one holding a harmless region name or a feature flag, yet both surface as the same single red recommendation. Map the failing accounts to what their variables actually contain and prioritise by what a leaked value would unlock.

The arithmetic is one-sided. The remediation is a short engineering task and a policy assignment. The downside of leaving it is a plain-text credential sitting in a service many people can read, which is exactly the kind of standing secret that turns a minor account compromise into lateral movement across the estate.

This lesson is for the finance partner who sees an 'Automation account variables should be encrypted' finding and wants to know what it costs to fix and how much risk it carries. It covers why the remediation is free in Azure spend, why the real cost is a short engineering task, and how to prioritise the accounts whose variables actually hold credentials.

Fun fact

The variable that outlived the runbook

How a finance partner frames the automation-encryption decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with an 'Automation account variables should be encrypted' finding on the operations account. The instinct is not to wave through a remediation budget; it is to ask what the variables actually hold and what it costs to fix. The answer on cost is the easy part: encrypting an Automation variable changes nothing on the Azure bill, because the per-account encryption key is managed by Automation itself with no Key Vault charge. The whole cost is a short engineering task.

Sam asks the team to map each plain-text variable to what it contains. One holds a production SQL connection string, one a Slack webhook URL, and the rest are harmless: a region name, a couple of feature flags, a retention-day count. The list is reframed on the risk register: the connection string is a high expected-loss item to seal today at zero Azure cost, the webhook is a lower but real exposure to recreate, and the harmless values can be left or tidied at leisure. The finance pack reads: 'One plain-text production credential to seal now, one webhook to recreate, no incremental Azure spend; the only thing between us and a clean finding is a short engineering task and a policy assignment.'

Why unencrypted automation variables belong on the risk register

The cost model here is as one-sided as security work gets. Sealing the variables costs nothing in Azure spend, because the encryption is built into the Automation account with no Key Vault or premium-tier charge. Leaving them open creates an unbounded tail risk: a standing, non-expiring credential that anyone with read access can lift and that often unlocks more than Automation itself.

The documented cost of a leaked production credential is the cost of whatever it unlocks: a database, a third-party service, a privileged account, plus the breach notification, forensics and legal fees that follow. Against that, the remediation is a short engineering task to recreate a handful of sensitive variables and a policy assignment. The finance role is to attach expected loss to each failing account based on what its variables actually contain, so the work is prioritised by what a leaked value would cost, not by the single red finding count.

What finance can do about the automation-encryption gap

Finance cannot recreate a variable, but it owns the framing that turns a single red finding into a risk-ordered plan with zero incremental Azure spend. Three levers.

1. Confirm the remediation is free, not a spending decision

Make it explicit that encrypting an Automation variable costs nothing in Azure spend: the per-account key is managed by Automation with no Key Vault charge, no premium tier and no per-secret fee. The only cost is a short engineering task. That removes any argument that the capability needs a budget line and reframes it purely as work to schedule.

2. Order the work by what a leaked value would unlock

A plain-text connection string and a plain-text region name both sit behind the same single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each plain-text variable to what it contains and prioritise the credentials, keys and connection strings first. The metric for the review is the count of plain-text variables weighted by the sensitivity of what they hold, not the raw recommendation status.

3. Require a backstop, not just a one-off sweep

A clean-up that is not backed by policy will drift straight back as the next runbook adds the next plain-text variable. Ask for the built-in policy to be assigned with a Deny effect once the estate is cleaned, so the finding cannot quietly return. The difference between 'we fixed it once' and 'it cannot recur' is one policy assignment at no cost.

Quick quiz

Question 1 of 5

An 'Automation account variables should be encrypted' finding lands. As the finance partner, what is the right starting assumption about its Azure-spend cost to fix?

Keep learning

Go deeper on how Azure Automation stores variables and the encryption choice behind this capability.

You have finished the finance view of encrypting automation variables. You know the cost model is one-sided: sealing the variables is free in Azure spend, the only cost is a short engineering task, and the downside of leaving a plain-text credential open is the documented cost of whatever it unlocks. Next time the finding lands, you will order the work by what a leaked value would unlock, ask for the deny policy as the backstop, and treat the most-shared secrets as a Key Vault question rather than asking how much remediation will cost.

Back to the library

Encrypting automation data: the headline

Whether the secrets your automation runs on are sealed or sitting in plain text

Automation is the machinery that keeps the estate running, and it carries credentials to do its job. The leadership question is simple: are those credentials encrypted, or are they readable by anyone with access to the Automation account? An unencrypted variable holding a key or connection string is a standing secret that does not expire and does not rotate, waiting to be read.

The defensible end state is that every Automation account variable holding sensitive data is an encrypted secure asset that can never be read back, only used, and that an Azure Policy flags any new plain-text variable before it becomes the next forgotten credential.

This is not a cost decision. Encrypting automation variables is free in Azure terms. It is a governance decision about whether the secrets your automation depends on are protected by design or only by everyone remembering to tick a box.

A short read for the leader who needs to know what an unencrypted automation variable exposes, why sealing it is a governance decision rather than a budget one, and what a defensible end state looks like across the estate.

Fun fact

The variable that outlived the runbook

What it looks like when automation secrets are sealed by design, not habit

After a security review turned up a production database password sitting in plain text inside an Automation account that a dozen engineers could read, the question at the next leadership review was the obvious one: how many more of those are there, and how would we know? The honest answer at the time was that nobody knew, because whether a variable was encrypted depended entirely on whether whoever created it remembered to tick the box.

The team's response was to stop treating it as a one-off cleanup and start treating it as a guardrail. They listed every variable across every Automation account, recreated the ones holding credentials as encrypted secure assets, and then assigned an Azure Policy that flags any Automation account that still holds a plain-text variable. The next time the question came up, the answer had changed from 'we are not sure' to 'every sensitive automation variable is sealed, and the policy tells us the moment a new plain-text one appears.' That shift, from relying on people remembering to encrypt to making the unencrypted state visible automatically, is the confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Why this is a board-level risk

Automation holds the credentials that keep the estate running, and those credentials are often powerful. A plain-text variable is a standing secret that does not expire and is rarely rotated, which makes it exactly the kind of forgotten credential that turns a small intrusion into a serious one. Sealing it is the control that removes that standing risk, and an Azure Policy backstop keeps it removed.

The cost of getting this wrong is whatever the leaked credential unlocks, which is usually far more than the Automation account itself, while the cost of fixing it is essentially a short engineering task. This is the class of control where the risk of inaction is severe and the cost of action is trivial, which is exactly the trade leadership should approve fastest.

The leadership move on automation secrets

The executive handle is not to approve each variable fix; it is to require that every sensitive automation variable is encrypted and that a policy prevents new plain-text ones, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which every Automation account is inventoried, the variables holding credentials are recreated as encrypted secure assets, and the built-in policy is assigned with a Deny effect so no new plain-text variable can be created. A backstop that no individual variable can bypass is the difference between encrypting what was there and guaranteeing nothing plain-text can be added tomorrow.

2. Ask for proof, not assurance

The proof is not a verbal 'we cleaned it up.' It is a passing 'Automation account variables should be encrypted' recommendation across every account plus evidence the deny policy is assigned. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with lead time before any audit deadline rather than the morning of.

3. Treat shared credentials as a Key Vault question

Where a credential is used by several runbooks, the better end state is often to move it into Key Vault and reference it, so it lives in one managed, auditable, rotatable place rather than being copied into multiple Automation variables. The leadership requirement is simple: no powerful secret should sit in plain text, and the most-used ones should have a single owned home.

Quick quiz

Question 1 of 5

At a review you ask whether a forgotten plain-text credential could be lurking in your automation. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure Automation stores variables and the encryption choice behind this capability.

Two takeaways. Encrypting automation variables is the rare control where the risk of inaction, a standing credential that often unlocks more than Automation itself, is severe and the cost of action is essentially a short engineering task, so it is the trade you should approve fastest. And the defensible end state is not 'we cleaned it up once'; it is every sensitive variable sealed as a secure asset plus an Azure Policy that denies new plain-text ones, making forgotten credentials structurally hard to leave behind.

Back to the library

Part of the learning path Encrypt across Azure

Encrypt Azure automation and configuration data

Encrypting automation data: the basics

The variable that outlived the runbook

Finding unencrypted variables across an Automation account

How Defender for Cloud decides an Automation variable is exposeddeep dive

What is the impact of leaving automation variables unencrypted?

How do you encrypt automation variables safely?

1. Inventory every variable by encryption state

2. Separate real secrets from harmless values

3. Recreate the sensitive variables as encrypted assets

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Encrypting automation data: the cost and risk view

The variable that outlived the runbook

How a finance partner frames the automation-encryption decision

Why unencrypted automation variables belong on the risk register

What finance can do about the automation-encryption gap

1. Confirm the remediation is free, not a spending decision

2. Order the work by what a leaked value would unlock

3. Require a backstop, not just a one-off sweep

Quick quiz

Keep learning

Encrypting automation data: the headline

The variable that outlived the runbook

What it looks like when automation secrets are sealed by design, not habit

Why this is a board-level risk

The leadership move on automation secrets

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat shared credentials as a Key Vault question

Quick quiz

Keep learning

Related compliance lessons