You moved SFTP logins to Entra SSO. The service accounts still use static passwords.

"SFTP is behind Entra SSO now" is a sentence that has ended more than one board discussion early. The director shows a coverage figure in the high nineties and moves on. It is accurate, and it counts the wrong people. It counts the handful of humans who sign in to eyeball a folder. It ignores the cron jobs, the partner ETL processes, and the integration middleware that actually move the files, which still authenticate with a static password or shared key that no MFA prompt ever sees.

The gap stops being subtle the moment you look. The credentials that carry the most volume and live the longest are precisely the ones outside identity governance. An attacker who has taken a partner connection and an auditor pulling your access review both head to the same place first: the service accounts.

Two authentication populations: humans and machines

SSO rollouts are designed around human sessions. A person hits a login page, gets redirected to Entra, completes MFA, and the session token expires within hours. Conditional access can demand a managed device, a known location, a passing risk score. That apparatus assumes a browser with a person behind it.

A nightly batch job from a logistics partner has none of it. It opens an sftp connection from a fixed IP, presents a password or a key, moves a few thousand invoices, and disconnects. No redirect, no consent screen, no second factor. When your dashboard reports a coverage percentage, ask which population sits in the denominator. It is almost always the small one.

Why service accounts hold the volume and the static secrets

The machine population is where the data lives. A human might pull one report a week. A partner integration fires every fifteen minutes and moves gigabytes a day for years while nobody touches the config. That same property is what makes the credential dangerous: it was set once, written into a script, mailed to the partner back in 2021, and never rotated, because rotating it means a change window with an external team that does not answer quickly.

So the highest-volume connection holds the longest-lived, most-shared, least-watched secret in the estate. Static passwords for service accounts are not a smaller version of the human problem. They are the larger problem wearing the human problem's compliance badge.

Key-based and short-lived credentials for machine transfers

Machine transfers do not need an interactive identity provider. They need a credential that is non-interactive, scoped, and short-lived. When Azure Blob Storage added Entra ID support for SFTP, it pointedly did not bolt password auth onto machine clients, because no SFTP client speaks Entra natively. Instead it issues an OpenSSH certificate that lives for roughly an hour, then expires on its own.

Bringing automated integrations under the same control

The fix is not to drag machines through a human login flow. It is to make the machine population visible to the governance you already apply to people: every automated account gets a named owner, a scope, an expiry, a rotation record, and an audit trail that ties a file movement back to a specific credential. If your access review covers human SSO while the service accounts live in a spreadsheet nobody reads, you have not closed the gap. You have documented it.

In xEvolve, human operators and automated integrations share one Environment under a single identity and audit model, so a service account is governed, scoped, and logged the way a person is. See how the identity and audit controls handle the machine population, not just the people.