Single sign on solved the human password problem for most enterprises. The user has one credential, the SSO provider, and the user logs in once. The downstream applications trust the SSO assertion. The password manager handles the complexity. Phishing resistance is solved with FIDO2. The human password problem in 2026 is mostly a solved problem for the organisations that have actually deployed the technology.
What single sign on did not solve, and what the security industry has been quietly failing to address, is the service account problem. The service account predates SSO. The service account does not authenticate through SSO. The service account has a static credential, stored in a config file, in a CI pipeline, in a credential vault, in a database connection string. The service account has been accumulating in every enterprise since the 1990s, and the typical enterprise has roughly 10x more service accounts than human users. The service account is the dominant credential attack surface in 2026, and the defender who has celebrated solving the human password problem is missing the larger problem sitting underneath.
What the service account problem actually looks like
Five categories, all of them accumulating since before SSO became standard. First comes the Windows service account, running SQL Server, the backup agent, the print spooler, the monitoring agent. These accounts carry passwords that have not been changed in years, because changing them requires a maintenance window. The accounts hold local administrator rights because that was the path of least resistance when the application was deployed. The accounts continue running critical workloads today. Second comes the database application account, the account the web application uses to connect to the database. The account has read/write on the production database. The password sits in a config file, or in a secrets manager that nobody rotates. Third comes the CI/CD service account, the account the build pipeline uses to push to production. The account has write access to the production deployment targets. The account has been used by the build system for years. Fourth comes the cloud service account: the AWS IAM user, the GCP service account, the Azure service principal. These hold programmatic access keys that were generated when the application was deployed and have not been rotated. Fifth comes the integration account, the account the SaaS application uses to talk to the corporate database. The account has been authorised to read and write customer records. Nobody remembers the account exists.
The common pattern is that the account was set up by a developer who has long since left the organisation. The account is referenced in code, in CI pipelines, in documentation that nobody maintains. The account has the access it had when it was created. The access has never been reviewed. The credential has never been rotated. The account is a permanent, unmanaged, over privileged foothold in the production environment. When the attacker finds it, the attacker has the keys to the kingdom.
What to actually do
Three moves, in priority order. First comes inventory. The defender has to know what service accounts exist. The discovery tools (CyberArk, Venafi, HashiCorp Boundary, the cloud native identity discovery tools) produce a list. The list runs long. The list serves as the starting point. Second comes credential rotation. The service account passwords that have not been changed in over a year represent the priority. For the cloud service accounts, replace the static access keys with short lived credentials, where the cloud provider supports it (AWS IAM roles, Azure managed identities, GCP workload identity federation). Third comes access review. The service account that holds access it does not need represents the highest risk. The least privilege work that the security team has been deferring for human identities proves more urgent for service accounts. The service account that nobody has reviewed in 5 years serves as the one the attacker finds first.
The bottom line
SSO solved the human problem. The service account problem is now the bigger one. Inventory first, then rotate, then review access. The work is not glamorous. The work is necessary. The service account is the credential the attacker will find first.
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.
