4 MIN READ
Picture the average enterprise login in 2026. One human, one credential, one tap on a hardware key, and the employee is in. The password manager handles the long strings. FIDO2 handles the phishing. Single sign on passes the assertion to the downstream application. For most organisations that have actually deployed the technology, the human side of the credential problem is, for the most part, a solved one.
Here is the part nobody is celebrating. The service account problem amounts to the larger one, and the security industry has been quietly failing to address it for the better part of a decade. Service accounts predate SSO. They do not authenticate through it. They sit with static credentials in config files, CI pipelines, credential vaults, and database connection strings. The typical enterprise now runs roughly ten times as many of them as human users, and they have been quietly accumulating since the 1990s. They are the dominant credential attack surface in 2026, and the security org that has finished celebrating the human password problem has the larger one sitting underneath, unnoticed.
What the problem actually looks like in production
Five categories, all of them accumulating since before SSO became standard. Windows service accounts run SQL Server, the backup agent, the print spooler, the monitoring agent. Their passwords have not been changed in years, because changing them requires a maintenance window the application team never books. They hold local administrator rights because that was the path of least resistance when the application was deployed, and they continue running critical workloads today. Database application accounts connect the web application to the production database with read and write privileges. The password sits in a config file, or in a secrets manager that nobody rotates. CI and CD accounts push to production. They have write access to the deployment targets, and they have been used by the build system for years without anyone asking whether the access is still needed. Cloud service accounts (the AWS IAM user, the GCP service account, the Azure service principal) carry programmatic access keys that were generated at deploy time and have not been rotated since. Integration accounts link the SaaS application to the corporate database with read and write on customer records that nobody remembers granting.
The common pattern is that the credential was set up by a developer who has long since left the organisation. It is referenced in code, in CI pipelines, and in documentation that nobody maintains. The access has never been reviewed. The credential has never been rotated. It amounts to a permanent, unmanaged, over privileged foothold in the production environment, and whoever finds it has the keys to the kingdom.
What to actually do
Three moves, in priority order. Inventory first. The discovery tools (CyberArk, Venafi, HashiCorp Boundary, and the cloud native identity discovery products) produce a list, and it usually runs long: often five to ten times the size of the human directory. That output serves as the starting point for everything that follows. Rotation next. The non-human credentials that have not been changed in over a year are the priority, and for the cloud side the right answer is to replace the static access keys with short lived credentials where the provider supports it (AWS IAM roles, Azure managed identities, GCP workload identity federation). Access review third. The credential that holds access it does not need represents the highest risk. The least privilege work the security org has been deferring for human identities proves more urgent for the non-human side, and the credential nobody has reviewed in five years is the one the threat actor finds first.
The bottom line
Inventory, rotate, review. SSO solved the human problem. The non-human side is the larger one now, and the work to fix it is unglamorous, overdue, and the only thing standing between the defenders and the next breach that nobody saw coming.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
