Replace Service Accounts with Entra Workload Identities

Kill the “svc-” Era: Replacing Service Accounts with Entra Workload Identities for Real Zero Trust

TL;DR

Service accounts with static secrets and broad rights are your biggest identity gap. Workload Identities (in Microsoft Entra ID) give every non-human actor a governed identity with least privilege, lifecycle, CA policies, rotation, and full audit trails—without breaking your automations.

---

Why Service Accounts Fail (and break Zero Trust)

• Static secrets & no MFA → easy to steal, hard to rotate safely

• Over-privileged by default → “make it work” permissions become permanent

• No lifecycle → orphaned/forgotten accounts survive migrations and reorgs

• Thin auditability → “who used this and why?” = guesswork and screenshots

• Exception culture → CA/MFA exclusions for bots quietly widen your attack surface

---

Managed Identities: A Good Step—But Azure-Bound

• ✅ Secretless access for Azure-native resources (Functions, VMs, Logic Apps)

• ❌ Gaps for hybrid/third-party targets, weak ownership mapping, limited governance views

• ❌ CA/entitlements coverage not uniform across non-Azure surfaces

---

Workload Identities: What You Actually Get

• First-class non-human identities (apps, scripts, connectors, RPA, integrations)

• Scoped permissions (Graph/resource roles, app-only auth) with least privilege

• Lifecycle (owner, review cadence, decommission flow) tied to business process

• Conditional Access for workloads (risk/context-aware gates, session controls where supported)

• Credential hygiene (short-lived secrets, certificates, key rotation policy)

• Unified visibility (sign-ins, tokens, resource access, change history) → audit-ready

---

Comparison Matrix (at a glance)

Capability	Service Account	Managed Identity	Workload Identity
Secrets	Static passwords	Secretless (Azure)	Secretless/short-lived + rotation
Scope	Broad / user-like	Azure-centric	Any workload (apps/scripts/connectors)
CA / Risk	Rarely applied	Limited	Policy-driven where supported
Lifecycle	Ad hoc	Basic	Owner + reviews + decommission
Audit	Sparse	Azure logs	Centralized sign-in & entitlement trail

---

Architecture Patterns (common use cases)

• Power Platform connectors / cloud flows → Assign a workload identity per integration; grant only needed Graph/Dataverse scopes.

• Line-of-business apps (web APIs, daemons) → App registration + cert; use app roles + app-only Graph; enforce CA where applicable.

• Automation scripts (Azure Automation, GitHub Actions, DevOps) → Use federated credentials (OIDC), no stored secrets.

• Cross-tenant / B2B jobs → Dedicated workload identity per tenant boundary; isolate rights and logging.

---

Migration Playbook (90-day, low-drama)

Phase 1 — Discover & Triage (Weeks 0–3)

1. Inventory non-human sign-ins and objects: svc-*, app-*, shared mailboxes, app regs, secrets expiring <90 days.

2. Map each to owner, business purpose, targets, permissions, break glass dependency.

3. Risk rank: static passwords, global roles, no owner, no recent rotation.

Phase 2 — Convert High-Risk First (Weeks 4–8)

1. Stand up workload identity per integration (do not reuse).

2. Replace password auth with certs or federated credentials; set rotation.

3. Move to app-only permissions; remove user-delegated where not required.

4. Apply Conditional Access policies for workload sign-ins (where supported).

5. Implement access reviews (quarterly) + ownership in CMDB/ITSM.

Phase 3 — Decommission & Govern (Weeks 9–12)

1. Disable old service accounts; monitor for 14 days; then delete.

2. Enforce creation standards: naming, owner, data classification, review cadence.

3. Add alerting: anomalous sign-ins, inactive identities >30/60/90 days, expiring secrets.

4. Bake identity checks into CI/CD (policy-as-code).

---

Conditional Access & Permissions (practical guardrails)

• Separate policies for human vs. workload identities; block interactive logon for workloads.

• Named locations / network restrictions for app-only access where feasible.

• Time-bound entitlements (PIM for app roles where available; scheduled access reviews).

• Scopes: prefer app roles / resource-specific roles over directory-wide rights.

---

Logging & Audit (what to show the auditor)

• App/workload owner, purpose, data sensitivity

• Sign-in logs (service principal sign-ins), token audience, IP, client app

• Role assignments (who approved, when certified)

• Credential history (type, last rotation, expiry)

• Lifecycle: created/modified/disabled/deleted with change actor

---

KPI Dashboard (prove the improvement)

• % non-human identities with owner + review cadence (target ≥ 95%)

• Orphaned service accounts (target → 0)

• Secrets older than 90 days (target → 0; prefer cert/federated)

• App-only role breadth (count of “Directory.ReadWrite.All” → trending down)

• Audit findings for non-human access (quarter over quarter ↓)

---

Anti-Patterns to Eliminate

• Reusing a single generic service account across many systems

• Embedding passwords in scripts, web.config, or Key Vault with no rotation policy

• Granting Global Admin / Owner “just in case” to keep jobs running

• “Temporary” exceptions to CA that never expire

---

Quick Wins (this week)

• Tag every non-human identity with Owner, System, Data Class.

• Flip one high-risk job to federated credentials (GitHub OIDC → Entra).

• Replace a shared service account in Power Automate with a workload identity.

• Create a report of service principals with expiring/expired secrets; schedule alerts.

---

FAQ (fast answers)

Do workload identities break legacy on-prem jobs?
No—bridge with app-only auth, certificates, or broker services; retire passwords incrementally.

Can I enforce Conditional Access on non-human sign-ins?
Yes, for supported flows (service principal sign-ins). Use network/location/device signals where applicable and block interactive.

How do I avoid sprawl?
One workload identity per integration (not per team). Enforce naming + owner + reviews at creation; automate cleanup of inactivity.

What about Power Platform?
Use Service Principals / Workload Identities for connectors and Dataverse; stop using shared user accounts.

---

Conclusion

You can’t rotate your way out of service-account risk. Entra Workload Identities bring non-human access into the same Zero Trust, lifecycle, and audit model you already demand for people—without outages or heroics. Start with your riskiest “svc-” accounts, convert to governed workload identities, and make exceptions the exception again.