When an employee leaves an organization, it is clear that their access should be removed. With an application, service, or automated process, this is often less obvious.

Their accounts can remain active for years. The original developer leaves, the application changes owners, and permissions gradually expand. A password or key remains in the configuration because it is unclear who is responsible for it or when it should be changed.

Meanwhile, the system keeps running. Over time, however, no one knows exactly who is responsible for the access, what it is used for, or whether it is still needed.

Identity, account, and authentication credential

A technical identity represents an application, service, device, or automated process that needs access to systems and data.

Across different systems, it may use different accounts or identity objects, such as a service account, database user, API client, OAuth application, or cloud identity.

A single technical identity can therefore have multiple accounts. These accounts authenticate using a password, key, token, or certificate.

For every technical identity, it should be clear:

• which application or process it represents,
• who is responsible for it,
• which accounts and permissions it uses,
• which systems it can access,
• how it authenticates,
• when it should be changed or decommissioned.

If this information cannot be traced, the organization does not have full control over the access and cannot be certain that the right person or team is responsible for it.

Why technical identities easily fall out of control

A technical account is often created during an implementation, a system integration, or while solving an operational issue. As a result, it may not go through the same process as an employee account.

Four risks appear most often.

No clear owner

A developer created the account, IT operates the application, and another department uses its output. Everyone understands one part of the solution, but no one is responsible for the identity as a whole.

Excessive permissions

An application receives more permissions during deployment than it actually needs. What was meant to be temporary gradually becomes permanent.

Long-lived credentials

A password or API key may remain active for years even when no one knows exactly who is using it or why. If it is compromised, it can be difficult to determine the scope of the risk or quickly revoke access.

An incomplete lifecycle

An application is replaced or a project ends, but the original accounts, tokens, and permissions remain active in other systems.

The same rules apply as they do for people

Applications and automated processes also need a known owner, a clear purpose, and only the permissions they actually require.

For as long as a technical identity exists, it must be clear who is responsible for it. If that person changes roles or leaves the organization, responsibility needs to be transferred. IGA helps keep ownership information current and connect it to regular access reviews.

It must also be clear which accounts and permissions belong to which application. If several applications use the same account, it becomes harder to determine which one performed a specific action. That account also needs permissions for all the activities those applications perform, making it easy for it to accumulate more access than each application would need individually.

Accounts should therefore be separated by application and purpose.

Managing the lifecycle of passwords, keys, and tokens is equally important. The organization needs to know how they are managed and must be able to change or quickly revoke them when necessary.

When an application is decommissioned, shutting down the server is not enough. Its accounts must also be disabled, permissions removed, and associated keys, tokens, and certificates revoked.

AI agents are entering IAM too

Alongside traditional applications, organizations are increasingly introducing AI agents. They can work with enterprise data, use different tools, and independently perform permitted operations.

An agent therefore also needs its own traceable identity. It should not use its creator’s personal account or generic credentials belonging to another application.

For every agent, it should be clear:

• who is responsible for it,
• whether it acts independently or on behalf of a user,
• which data and operations it can access,
• how its activity can be traced,
• when its access should expire.

What makes agents different is that they may work with multiple systems and tools within a single task and independently carry out a sequence of actions across them.

As an agent gains new capabilities, additional access may gradually be added. Over time, it can become difficult to maintain a clear view of every system the agent can reach and what it is allowed to do there.

It is also important to distinguish between situations where an agent acts under its own identity and where it acts on behalf of a specific user.

From an IAM perspective, however, this is not an entirely new principle. The same fundamentals still apply: a known owner, least privilege, a controlled lifecycle, and an audit trail.

Start with the highest-risk access

If an organization does not yet manage technical and agent identities systematically, it makes sense to start with the highest-risk ones.

These typically include identities with administrative privileges, access to sensitive data, connections to multiple systems, long-lived keys, or no clear owner.

As part of an IGA implementation – or within existing processes – organizations can gradually add ownership information, accounts, permissions, and lifecycle rules, and regularly verify that they still match the identity’s original purpose.

Start with the technical identities that have the highest privileges. For how many of them can you currently identify their owner, and the reason they still exist?