Entra Workload Identities and Managed Identity Hygiene for Automation Accounts

Automation has become the connective tissue of modern operations across government, aged care, and enterprise environments. Scheduled runbooks reconcile billing, integration jobs move records between line of business systems, and background processes enforce compliance checks without human intervention. Each of these workloads needs an identity so that it can authenticate to Microsoft Entra ID and reach the resources it depends upon, and the way that identity is managed determines much of an organisation's exposure to credential theft.

For many years the default pattern was to register an application, generate a client secret or certificate, and store that credential somewhere the automation could read it. This approach works, but it creates a sprawling inventory of secrets that expire, leak into source control, and outlive the people who created them. Replacing stored secrets with managed identities removes an entire class of risk, and pairing that change with disciplined auditing of workload identity permissions keeps the benefit from eroding over time.

The hidden cost of stored secrets

A client secret is a password for a non-human account, and it carries all the weaknesses of a password with none of the protections organisations apply to staff. Secrets are frequently copied into configuration files, pipeline variables, and scripts, where they can be read by anyone with access to those artefacts. When a secret approaches its expiry date, someone must remember to rotate it, update every consumer, and confirm that nothing broke, and that burden tends to grow quietly until an unnoticed expiry causes an outage.

The governance problem is just as serious as the operational one. A long lived secret is a durable foothold for an attacker who obtains it, because it can be replayed from anywhere until it is revoked or expires. In regulated sectors such as government and aged care, demonstrating that no shared or stored credentials underpin critical integrations is increasingly part of assurance and audit expectations. Reducing the number of secrets in circulation therefore improves both the security posture and the evidence an organisation can present to assessors.

How managed identities change the pattern

A managed identity is a workload identity in Microsoft Entra ID whose credentials are issued and rotated by the platform rather than by your team. When an Azure resource such as an Automation Account, Function App, or virtual machine uses a managed identity, it requests short lived tokens from the platform at runtime, so there is no secret for an administrator to store, rotate, or lose. This shifts the responsibility for credential lifecycle onto Microsoft and removes the most common cause of credential sprawl in automation estates.

Managed identities come in two forms, and choosing between them matters for hygiene. A system assigned identity is tied to the lifecycle of a single resource and is deleted automatically when that resource is removed, which keeps orphaned identities to a minimum. A user assigned identity is a standalone object that can be shared across several resources, which reduces duplication but requires deliberate ownership so that it does not linger after the workloads it served are decommissioned. For Azure Automation specifically, migrating runbooks from the older Run As accounts, which relied on certificates, to managed identities is the Microsoft recommended path and eliminates the certificate renewal cycle entirely.

Auditing workload identity permissions at scale

Removing secrets solves the credential storage problem, but it does not by itself address the permissions those identities hold. Workload identities often accumulate broad directory roles and application permissions over time, frequently far beyond what a given runbook actually uses. A mature programme treats every workload identity as a privileged account and applies least privilege deliberately, granting narrowly scoped application permissions or Azure role assignments and reviewing them on a defined cadence rather than at the point of a breach.

Visibility is the foundation of that discipline, and Microsoft Entra provides several native tools to support it. Administrators can enumerate service principals and their assigned app roles and API permissions, identify credentials that are expiring or unused, and surface identities that have not authenticated recently and may be candidates for removal. The Microsoft Entra Workload ID plan extends this further with access reviews for service principals and Conditional Access policies that can restrict where a workload identity may authenticate from, which helps contain a compromised identity to known network locations.

Sustaining good hygiene depends on turning these capabilities into a repeatable routine rather than a one off clean up. Practical measures include tagging and documenting the owner and purpose of every user assigned identity, scheduling periodic access reviews, and alerting on the creation of new client secrets so that exceptions are visible and justified. Establishing a clear standard, such as managed identities for all new automation and a defined exception process for the rare cases where a secret is unavoidable, gives teams a consistent target and gives auditors a policy to test against.

Moving from intention to practice

The transition does not need to be disruptive if it is sequenced sensibly. A reasonable starting point is to inventory existing automation, identify which workloads still rely on stored secrets or certificates, and prioritise those with the broadest permissions or the most sensitive data access. Converting each workload to a managed identity, confirming it functions, and then removing the redundant secret produces measurable progress without a large change event.

Over time the goal is a state where new automation is provisioned with a managed identity by default, permissions are granted at the minimum scope required, and both identities and their access are reviewed on a schedule. This steadily shrinks the attack surface, reduces operational toil from rotation and expiry, and produces the kind of auditable control environment that government and enterprise assurance frameworks increasingly expect. The outcome is automation that remains reliable while depending on far fewer long lived secrets.

References

• Managed identities for Azure resources - Microsoft Learn
• Microsoft Entra Workload ID overview - Microsoft Learn
• Azure Automation account authentication overview - Microsoft Learn