Here’s a fact most admins won’t say out loud: service accounts are often your weakest security link and you can’t just ‘rotate the password’ out of this problem. Today, we compare traditional strategies with Microsoft Entra ID Workload Identities—the only approach built from the ground up for controlling non-human access. If you’re tired of patchwork solutions and want to see what a real upgrade looks like, you’re in the right place.The Mess We Inherited: Why Service Accounts Break Zero TrustIf you’ve ever wondered why a supposedly “locked down” environment still keeps you up at night, it almost always comes back to the service accounts that nobody wants to talk about. These aren’t just one or two special logins—almost every organization has a small army of them. Think about the classic pain points: those password spreadsheets tucked away in someone’s OneDrive, dusty little scripts running in the background of legacy apps, or the mythical “break-glass” admin account that only gets touched when things go sideways—if anyone remembers the password at all. The reality is, even the environments with strict MFA and lockdown everywhere else always seem to have a side door for these non-human users.Let’s be honest, the first time you try to audit privileged access in a large environment, you end up swimming upstream against a tide of forgotten service accounts. Admins mean well—they really do. Maybe IT inherited a few hundred of these accounts with vague names like “backup_job1” or “svc-legacyapp.” Maybe nobody’s quite sure what the account does, so it never gets disabled, just in case. You might go through the motions of password rotation, but there’s no magic wand to guarantee risk actually goes away. The uncomfortable truth here is that service accounts get a permanent hall pass. They’re almost never enrolled in MFA, and trying to force a conditional access policy usually brings down a dozen critical automations no one wants to touch. If security best practices are a checklist, these accounts are the box you never really get to tick.That’s where attackers start paying attention. In most of the Red Team reports I’ve seen, the easiest path to domain admin isn’t brute-forcing a user—it’s finding a service account that’s been holding the same static password for three years. Just have a look at the aftermath of incidents like the SolarWinds breach or even some of the better-documented ransomware attacks; more often than not, privileged service accounts are the keys that make lateral movement effortless. Why bother with phishing high-profile users when you can lift a plaintext credential from a config file or snag it from an old script nobody maintains? Service accounts are like the spare key under the doormat: attackers know exactly where to look, and they know the odds are good that nobody’s been checking there.The governance mess runs deeper. Even in organizations that pride themselves on “zero trust,” nothing about managing service accounts actually fits the model. Zero trust is supposed to mean every request gets checked, verified, and tracked. Service accounts have a different set of rules: they’re rarely monitored, operate with broad and sometimes unlimited permissions, and weave through on-prem, cloud, and every corner of your environment. There’s no consistent visibility, and not much appetite to clean things up since doing so risks breaking critical processes. It’s no surprise that identity lifecycle management falls off a cliff. A user leaves your company, HR can close their account in minutes. A legacy integration gets retired or replaced? Good luck tracking the ghost accounts left behind, especially when documentation is light.It’s a bit like installing top-of-the-line locks on your front door but leaving the back window wide open. The front might be bulletproof, but your weakest point is still inviting trouble—and you know the attackers will find it. That’s not just theory. Penetration tests and post-breach forensics keep showing the same lesson: service accounts get overlooked, they keep the same passwords, and the blast radius when they’re compromised is huge. What’s worse is the lack of visibility. You might have SIEM tooling for user actions, but try getting a clean log of what “svc-backup-02” did last Thursday. If you find anything at all, it probably raises more questions than it answers.Let’s talk about static credentials for a second. Passwords on service accounts don’t rotate automatically. They don’t have natural lifecycle events. If a business process changes, those accounts hang around “just in case” and slowly become orphaned. Someone might script a password change, but the number of scripts that just “keep working” with an old password is higher than anyone wants to admit. These ghost accounts start to pile up, each one a potential entry point for someone with the patience to look. Over time, those exceptions turn into permanent risks, especially with non-human users that touch many resources across cloud and on-prem.Of course, most IT teams want to move to zero trust for everything, but this is where reality checks in. Applying conditional access to a script or legacy automation usually means instant outages. MFA on a non-human user? If only. Usually, you end up handing over broad privileges to make sure the process doesn’t break, then praying nothing bad happens. These accounts force security teams into making exceptions that would never fly for real users—so every control becomes watered down before it ever gets to production.So here’s the punchline: zero trust isn’t failing because you have bad intentions or poor tools. It’s that the traditional way we treat service accounts is simply incompatible with the whole idea of zero trust. No matter how many layers you build for your users, if your non-human access stays in the shadows, the gap never closes. You’re always playing catch-up, just one missed account away from your next incident.Managed identities were supposed to patch this all up, with the promise of secret-free deployments and tight cloud integrations. But have they really fixed the problem, or just painted over the cracks?Managed Identities: Better, But Still a CompromiseAt first glance, managed identities look like they finally solve the service account headache. Developers get to skip secret storage, credentials never land in config files, and everything just works inside Azure. Grant the right permissions, and your app or automation picks up what it needs, no password vaults, no sticky notes, no calling someone in the middle of the night to find out where a credential is stored. There’s a reason cloud teams reach for managed identities as soon as they spin up a new resource—it’s the easy button that promises fewer secrets to rotate and less to worry about when securing cloud apps. You can even see the relief on a developer’s face when they realize they don’t have to hassle with key vaults or environment variables full of sensitive strings.But there’s a catch hiding in the fine print. Managed identities were designed with a strong Azure focus, and this shows in how—and where—they’re used. They work beautifully when you’re dealing with Azure Functions, Virtual Machines, Logic Apps, or anything that fits neatly into Microsoft’s cloud patterns. The trouble shows up the minute your environment colors outside those lines. As soon as you talk about integrating with on-premises systems, connecting to a third-party SaaS, or even orchestrating across multiple clouds, managed identities start to hit their limits. For a lot of organizations, those edge cases aren’t edge cases at all—they’re the reality that makes things work.Picture the sprawl of your typical hybrid setup: part of your app stack lives in Azure, but there are legacy databases on-prem, file shares in odd places, and some parts tucked into AWS or Google Cloud. Managed identities, as they stand, don’t cover all these scenarios. So, while you get secretless authentication for Azure resources, those same workloads still need old-school credentials to reach most other things. The promise of “no secrets, no manual cleanup, no headaches” falls apart at the boundaries. It’s like paving a beautiful road that ends at your property line—the traffic keeps going, but the asphalt stops.And for all their strengths, managed identities don’t offer fine-grained lifecycle management. You can grant or revoke access, but figuring out which applications are actually using which identities rarely feels straightforward. Tracking usage isn’t built in, auditing changes is basic at best, and if something goes stale, you might not notice until it causes an outage or gets flagged during an audit. When it’s time to clean things up—say you retire a workload or move to a different integration—you’re back to spreadsheets and manual reviews, double-checking which managed identities can safely be removed and which are still active somewhere else. There isn’t an easy way to link a managed identity to a business owner or hold someone accountable for its existence, so orphaned identities accumulate just like the service accounts they were meant to replace.Conditional access introduces another wrinkle. Enforcing strong policy controls on a managed identity isn’t the same as with user identities. The guardrails for least privilege, step-up authentication, or context-aware access don’t really translate over. Most managed identities are all-or-nothing: you set broad permissions because you don’t want to break things, and then you leave them alone. If you want to see who’s using a managed identity, why, and from where, the logs are thin. There’s no entitlement management or deep integration with high-level governance checks. Auditors will still ask—who approved this access, who reviews it, can you prove it’s been shut off when no longer needed? Most organizations are left cobbling together answers using Azure Activity Logs, custom scripts, and a bit of hoping for t

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.