Most CISOs at Australian mid-market organisations can describe their user identity posture confidently. MFA coverage. Conditional Access policies. Phishing-resistant credentials on privileged roles. Defender for Identity. The maturity has lifted dramatically since 2020. Threat actors have noticed and pivoted.
The pivot is to workload identities. Service principals. App registrations. OAuth-consented third-party apps. Managed identities. Federated workload credentials. They authenticate the same way users do, against the same Entra ID, calling the same Microsoft Graph. They have no MFA. There is no human at the keyboard. They have credentials — usually a client secret or a certificate — that, if leaked, give the attacker exactly the access the app holds.
The two most consequential Microsoft incidents of recent years pivoted through this surface. Storm-0558 in 2023 abused a leaked Microsoft consumer signing key to forge tokens for enterprise mailboxes. Midnight Blizzard in 2024 compromised a legacy OAuth application to read corporate Microsoft mailboxes. In both, user MFA was irrelevant. The exploit path was workload identity.
What we find when we audit AU mid-market tenants
Frontrow has audited workload identity posture across Australian professional services, regulated industry and regional operator tenants. The pattern is consistent enough to publish.
- Hundreds of consented third-party apps with no inventory and no owner. Most were consented by users, not admins. Most were consented years ago by people who have since left.
- Dozens of App Registrations created for one-off integrations. The integration was decommissioned. The App Registration kept its overprivileged Graph permissions and its 24-month client secret.
- Service principal client secrets created at default 24-month expiry, never rotated. The 'rotate' diary entry was never made.
- Mail.ReadWrite.All, Files.ReadWrite.All, Directory.ReadWrite.All granted to apps that need a fraction of that scope. The developer asked for everything 'just in case'. Nobody pushed back.
- Conditional Access for Workload Identities not enabled. Workload Identities Premium licence was either not purchased or purchased and not turned on.
- App Governance (Defender for Cloud Apps) not configured. No behavioural baseline on what each app should be doing. No alert when an app starts behaving differently.
Why this is the new front line
User-centric defences have hardened. MFA is widespread. Phishing-resistant MFA on privileged roles is now baseline expectation under Essential Eight ML2. The cost of compromising a user's session has gone up.
Workload identity defences haven't moved at the same pace. Microsoft introduced Conditional Access for Workload Identities in 2022. Most tenants haven't adopted it. App Governance shipped in Microsoft Defender for Cloud Apps. Most tenants don't run it. The attacker calculus has shifted: a service principal with Mail.ReadWrite.All on the tenant is a higher-leverage target than a single user account, harder to defend, and almost certainly under-monitored.
The five gaps that matter most
1. App registration inventory
You cannot govern what you don't know exists. The first finding in nearly every audit is that no inventory of App Registrations is maintained. Build one. Microsoft Graph (or the Entra portal export) gives you the list. Assign a named business owner to each. Quarterly review. Disable apps with no owner. This sounds basic. It isn't done.
2. Consent governance
Default Entra ID lets users consent to third-party apps requesting low-risk Graph scopes. Adversary-in-the-middle phishing campaigns now route through OAuth consent rather than password capture — the user clicks 'allow' on a phishing app and the attacker gets a refresh token that survives MFA, password change and session revocation. The fix is the admin consent workflow. Most tenants either leave user consent on (the dangerous default) or switch admin consent on without staffing the queue (which leads to legitimate apps blocked and shadow-IT consent paths reopening).
3. Graph permissions hygiene
Microsoft Graph application permissions are tenant-wide and unattended — there is no user-context check. An app with Mail.ReadWrite.All can read and write every mailbox in the tenant, irrespective of which mailbox the data flows to or from. Audit your high-risk Application permissions: Mail.ReadWrite.All, Files.ReadWrite.All, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Sites.FullControl.All. For each, confirm the app actually exercises the permission and that the least-privilege alternative isn't viable. Microsoft publishes least-privilege guidance for every common Graph scenario.
4. Credential type and rotation
Service principal client secrets created at the default 24-month expiry, never rotated, are the workload identity equivalent of a stale local admin password. Move to certificates where the workload supports them. Move to Federated Identity Credentials where the workload runs on Azure, GitHub Actions, or another supported identity-federation host — that eliminates secrets entirely. For workloads that genuinely need secrets, set 12-month expiry, store in Key Vault, monitor expiry, rotate as a runbook step.
5. Conditional Access and behavioural detection
Conditional Access for Workload Identities — a Microsoft Entra feature requiring Workload Identities Premium or Entra ID P2 — lets you scope service principal sign-ins by IP, country and risk. A leaked credential in a public GitHub repo is unusable from outside your IP allowlist. Pair it with App Governance in Microsoft Defender for Cloud Apps for behavioural detection: an app that suddenly starts downloading data at midnight from an unusual location triggers an alert, regardless of whether the credential is valid.
Try it
Score your workload identity posture in 5 minutes
The Workload Identity Risk Check scores your tenant across all five areas. Output is a board-grade PDF with the gaps surfaced.
10 questions · 5 domains
Workload Identity Risk Check
Service principals are the blind spot in most M365 tenants. Score how exposed your app registrations, consented apps, and workload identities are — across the five areas that nation-state actors actually exploit. Pick the option closest to how your tenant is configured today.
Domain 1
App registration governance
Inventory, ownership and lifecycle of App Registrations (the publisher of a service principal). Most tenants have apps registered years ago by people who left the company.
Do you have a maintained inventory of every App Registration in your tenant, with a named owner?
Source: Microsoft Learn: Application and Service Principal objects in Microsoft Entra ID; ASD Essential Eight Maturity Model — Restrict Administrative Privileges.
How are App Registrations decommissioned when no longer needed?
Source: Microsoft Learn: Microsoft Entra app management best practices.
Domain 2
Consent and admin-consent governance
Whether users can consent to third-party apps freely, or whether admin consent is required and reviewed. The single most-exploited misconfiguration in M365.
Can users in your tenant consent to third-party apps without admin approval?
Source: Microsoft Learn: Configure user consent settings; Microsoft Entra Admin consent workflow.
How is admin consent for new apps reviewed?
Source: Microsoft Learn: Microsoft Entra admin consent workflow; Cloud Application Administrator role.
Domain 3
Graph permissions hygiene
Whether app permissions follow least-privilege, are reviewed, and avoid the well-known dangerous permissions (Mail.ReadWrite.All, Files.ReadWrite.All, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory).
How do you audit dangerous Graph application permissions (Mail.ReadWrite.All, Files.ReadWrite.All, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory)?
Source: Microsoft Learn: Microsoft Graph permissions reference; Microsoft Entra Permissions Management.
When a developer requests Graph permissions for a new app, what's the default posture?
Source: Microsoft Learn: Microsoft Graph least privileged permissions reference.
Domain 4
Service principal credentials
Whether service principals use certificates rather than long-lived secrets, whether credentials rotate, and whether secrets are inventoried.
How do service principal credentials (client secrets, certificates) get rotated?
Source: Microsoft Learn: Add and manage application credentials in Microsoft Entra ID; Azure Key Vault key rotation.
What credential type do your service principals predominantly use?
Source: Microsoft Learn: Workload identity federation; Federated Identity Credentials for Microsoft Entra apps.
Domain 5
Conditional Access and detection
Whether Conditional Access for Workload Identities is enforced (P2 / Workload Identities Premium), and whether sign-in and admin-consent activity is monitored.
Is Conditional Access for Workload Identities enforced on your service principals?
Source: Microsoft Learn: Conditional Access for Workload Identities (requires Workload Identities Premium / Entra ID P2).
How is anomalous service principal behaviour detected?
Source: Microsoft Learn: App governance in Microsoft Defender for Cloud Apps; Microsoft Entra service principal sign-in logs.
This is an indicative self-assessment. It is not a substitute for a tenant-level workload identity audit. For verified results Frontrow Technology offers an in-tenant workload identity governance review.
What the managed program looks like
Workload identity governance is recurring work, not a project. The pattern Frontrow runs across Australian mid-market tenants is the Managed Identity & Information Protection program: quarterly review of every workload identity, app registration and consent grant; drift detection on Graph permissions; credential rotation tracking; Conditional Access for Workload Identities deployed and tuned; App Governance configured and triaged; monthly delta report to the IT lead, quarterly board-grade summary.
If you read this and recognise the pattern in your own tenant — you almost certainly do — that's the engagement. Email Frontrow at info@frontrow.email and we'll scope it.