The Identity Architecture Problem Nobody Audits

When you create an Azure Automation account without explicitly configuring a managed identity, the platform historically provisioned a Run As Account—a self-signed certificate-based service principal registered in Entra ID. Microsoft deprecated this feature in September 2023 and announced end-of-support for March 2024, but the critical operational reality is that thousands of enterprise tenants still have active Run As Accounts that were created before deprecation and have never been migrated.

The architectural problem is threefold.

First, the Run As Account service principal is assigned Contributor rights to the subscription by default. That is not least-privilege. That is a standing privileged identity with no MFA requirement, no Conditional Access policy enforcement, and no device compliance check—because service principals are excluded from the device-based CA policy framework by design.

Second, the self-signed certificate used for authentication has a default validity of one year, but many organizations renew it automatically through scripts without rotating the underlying service principal credentials or auditing what permissions have accumulated on that principal over time. The principal ages, the permissions grow, and nobody reviews it because it is not a human identity.

Third—and this is the cross-tenant escalation vector—when runbooks are granted Exchange Online, SharePoint, or Microsoft Graph permissions directly on the service principal (a common pattern for automation of M365 tasks), those permissions are not scoped by Conditional Access location policies, sign-in risk policies, or Intune compliance requirements. An attacker who exfiltrates the Run As Account certificate can authenticate from any device, any network, any geography, and the authentication will succeed.

---

Detection: Finding Exposed Run As Accounts and Anomalous Service Principal Sign-Ins

Detection requires two parallel workstreams: inventory and behavioral monitoring.

Inventory: Identify Active Run As Accounts

Run this against your Azure environment to enumerate all Automation accounts that still have active Run As Account configurations:

$Subscriptions = Get-AzSubscription

foreach ($Sub in $Subscriptions) {
    Set-AzContext -SubscriptionId $Sub.Id | Out-Null

    $AutomationAccounts = Get-AzAutomationAccount

    foreach ($AA in $AutomationAccounts) {
        $Connections = Get-AzAutomationConnection `
            -ResourceGroupName $AA.ResourceGroupName `
            -AutomationAccountName $AA.AutomationAccountName `
            -ErrorAction SilentlyContinue

        $RunAsConnections = $Connections | Where-Object {
            $_.ConnectionTypeName -eq "AzureServicePrincipal"
        }

        if ($RunAsConnections) {
            [PSCustomObject]@{
                Subscription       = $Sub.Name
                ResourceGroup      = $AA.ResourceGroupName
                AutomationAccount  = $AA.AutomationAccountName
                RunAsConnections   = ($RunAsConnections.Name -join ", ")
                Location           = $AA.Location
            }
        }
    }
}

Behavioral Monitoring: KQL for Anomalous Service Principal Authentication

In Microsoft Sentinel or Defender XDR Advanced Hunting, use this KQL query to surface non-interactive service principal sign-ins that originate from unexpected IP ranges or that access high-value resources outside business hours:

// Detect anomalous non-interactive service principal sign-ins
// Target: Automation Run As Account service principals accessing M365 resources
// Tune: Replace IP ranges and application display name patterns for your environment

let KnownAutomationIPs = dynamic(["<your-azure-automation-egress-IPs>"]);
let SensitiveApps = dynamic([
    "Microsoft Graph",
    "Office 365 Exchange Online",
    "SharePoint Online",
    "Microsoft Defender ATP"
]);

AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where UserType == "servicePrincipal" or isempty(UserType)
| where ResourceDisplayName in (SensitiveApps)
| where IPAddress !in (KnownAutomationIPs)
| extend ParsedLocation = parse_json(LocationDetails)
| extend City = tostring(ParsedLocation.city)
| extend Country = tostring(ParsedLocation.countryOrRegion)
| project
    TimeGenerated,
    AppDisplayName,
    ResourceDisplayName,
    ServicePrincipalName,
    IPAddress,
    City,
    Country,
    ResultType,
    ConditionalAccessStatus,
    AuthenticationRequirement
| where ConditionalAccessStatus == "notApplied"
| order by TimeGenerated desc

The ConditionalAccessStatus == "notApplied" filter is the critical signal here. Service principal authentications where CA was not evaluated represent authentications that bypassed your entire Conditional Access framework. Every result in this query is a sign-in that your CA policies did not touch.

---

Remediation: Migrating to System-Assigned Managed Identity

Microsoft's recommended migration path is to replace Run As Accounts with system-assigned managed identities on the Automation account. This eliminates the certificate-based authentication surface entirely. Managed identities use the Azure Instance Metadata Service for token acquisition—there is no exportable credential.

The migration sequence for an enterprise environment requires careful sequencing to avoid breaking production runbooks.

Phase 1: Enable Managed Identity on the Automation Account

$ResourceGroup      = "rg-automation-prod"
$AutomationAccount  = "aa-enterprise-prod"

$AA = Set-AzAutomationAccount `
    -ResourceGroupName $ResourceGroup `
    -Name $AutomationAccount `
    -AssignSystemIdentity

$ManagedIdentityObjectId = $AA.Identity.PrincipalId
Write-Output "Managed Identity Object ID: $ManagedIdentityObjectId"

New-AzRoleAssignment `
    -ObjectId $ManagedIdentityObjectId `
    -RoleDefinitionName "Reader" `
    -Scope "/subscriptions/<subscription-id>"

Phase 2: Update Runbooks to Use Managed Identity Authentication

Replace Connect-AzAccount calls that reference the Run As Account certificate with the managed identity authentication pattern:

Connect-AzAccount -Identity

$GraphToken = (Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com").Token

$Headers = @{
    "Authorization" = "Bearer $GraphToken"
    "Content-Type"  = "application/json"
}

$Response = Invoke-RestMethod `
    -Uri "https://graph.microsoft.com/v1.0/users" `
    -Headers $Headers `
    -Method GET

$Response.value | Select-Object displayName, userPrincipalName, id

Phase 3: Revoke and Delete the Run As Account Service Principal

After validating runbooks operate correctly with managed identity, remove the Run As Account service principal from Entra ID. Do not simply disable it—delete it and remove the associated app registration to eliminate the attack surface entirely.

Document every Graph API permission that was assigned to the old service principal before deletion. Those permissions must be re-granted to the managed identity's service principal in Entra ID with explicit admin consent, scoped to the minimum required permissions.

---

Governance Gaps This Creates in SOC2, FedRAMP, and Purview

The Run As Account misconfiguration is not just a technical risk—it is a compliance documentation failure.

SOC2 Type II requires evidence that privileged access is controlled, reviewed, and time-limited. A service principal with Contributor rights and a self-signed certificate that auto-renews does not satisfy the access review requirement. If your auditors pull Entra access reviews and find no review cadence for service principals with M365 permissions, that is a finding.

FedRAMP Moderate and High controls under AC-2 (Account Management) and IA-5 (Authenticator Management) explicitly require that non-human identities be subject to the same credential management lifecycle as human accounts. Certificate-based service principals with multi-year effective lifespans (through renewal scripts) violate IA-5(1) requirements for credential rotation and IA-5(7) prohibitions on unencrypted static authenticators in accessible locations.

Microsoft Purview data governance controls become partially blind when automation runbooks access SharePoint or Exchange data using service principal credentials that are not subject to Purview's sensitivity label enforcement for interactive sessions. Runbooks that move, copy, or process labeled content bypass the interactive DLP enforcement layer—the automation context does not trigger the same sensitivity evaluation that a user session would.

The audit gap in Entra sign-in logs compounds all of these. Non-interactive sign-in logs are not surfaced in the default Entra ID audit workbooks. Unless your SOC has explicitly built detections against AADNonInteractiveUserSignInLogs, service principal authentication activity from Automation accounts is effectively invisible in standard compliance reporting.

---

Recommendations for Enterprise Architects

These are not aspirational guidelines. These are the specific actions required to close this gap in a production M365 environment.

Immediate actions (within 30 days):

• Run the inventory script above across all subscriptions. Produce a register of every active Run As Account service principal, its assigned roles, and its Graph API permissions.
• Pull the last 90 days of AADNonInteractiveUserSignInLogs for each identified service principal. Flag any sign-ins from IPs outside your known Azure egress ranges.
• Disable auto-renewal scripts for Run As Account certificates. Do not let the attack surface extend itself while you plan migration.

Short-term remediation (30–90 days):

• Migrate all Automation accounts to system-assigned managed identities following the phase sequence above.
• Scope managed identity role assignments to resource group or resource level—not subscription level. Subscription-level Contributor is almost never the minimum required permission.
• Implement Entra access reviews for all service principals with Graph API application permissions. Set review cadence to quarterly minimum.

Structural governance (ongoing):

• Add AADNonInteractiveUserSignInLogs to your Sentinel analytics rules with the KQL query above as a baseline detection.
• Include service principal credential inventory in your SOC2 and FedRAMP evidence packages. Auditors increasingly ask for this specifically.
• Establish a policy that no new Automation account may be created without a managed identity configuration—enforce this through Azure Policy with a deny effect on Automation accounts that lack a system or user-assigned identity.

---