Local accounts, break-glass logins and hardcoded credentials inside applications

What is a local account?

A local account lives in the application's own user store. Someone created it inside the application, not in the identity provider, and the application checks its password or key itself. Local accounts are normal: many applications need at least one administrator who can sign in when single sign-on is down. The trouble starts when nobody keeps a list.

Which kinds turn up most often?

• Local administrators created during setup and never removed.
• Break-glass accounts kept for emergencies, often shared by a small team.
• Vendor and support logins created for an implementation partner.
• Test and training accounts that outlived the project.
• Integration users that one system uses to call another.
• Hardcoded credentials: a username and password, or a key, written into code, a script or a configuration file.

Why do they survive offboarding?

Offboarding in the identity provider disables the person's central identity and, where a connector exists, the accounts it provisioned. A local account has no link to that identity. If a leaver knew the password of a shared admin account, disabling their IdP account changes nothing. If a hardcoded credential belongs to a departed engineer, it keeps working until someone finds and rotates it.

Why do hardcoded credentials need separate treatment?

They are not attached to a person at all. The OWASP Non-Human Identities Top 10 lists Secret Leakage (NHI2) and Long-Lived Secrets (NHI7) among its risks, alongside Improper Offboarding (NHI1). A credential in code tends to be long-lived because changing it means changing the code that uses it.

How do the tools here find them?

The vendors document different routes, as recorded on this site:

• Veza states that its access reviews reveal all accounts with access, including local, machine and service accounts, even if they exist outside your identity platforms.
• Orchid Security lists local user activity and hardcoded accounts and credentials among the things it detects inside applications.
• Lumos describes revoking access across local accounts as part of offboarding.
• Microsoft Entra ID Governance documents account discovery that shows users in an application who do not match any Entra ID user.

Each route depends on how the tool reaches the application, which lesson 7 covers.

What should a clean-up look like?

1. List the local accounts in each application, including disabled ones that can be re-enabled.
2. Match each one to a current person, a system or nothing.
3. Give every account an owner, or remove it.
4. Move shared emergency logins to a process with a named custodian and a record of use.
5. Rotate hardcoded credentials and move them out of code where the application allows it.
6. Repeat on a schedule, because new local accounts appear whenever someone needs a quick fix.

Sources