Picture an access review at a bank, the kind that happens once a year because an auditor asked for it. Somewhere in the export is an account belonging to a contractor who finished a core banking integration project. It is still active, carrying VPN access, a certificate that has auto-renewed twice, membership in three Active Directory groups and a login to the reconciliation application. Nobody has used it in nineteen months. The contractor has been working somewhere else for most of that time.

Nobody did anything wrong. The manager who engaged him moved teams. The contract lapsed quietly rather than being terminated. HR had no record of him because he was never an employee, and the offboarding checklist that would have caught him only runs when HR files a separation. The ticket that created his access was closed and archived the week it was raised. No single system knew he existed, and no single person had the job of noticing.

This is not a story about negligence. It is a story about accounting. Every organisation that grows accumulates identity debt the same way it accumulates technical debt, through a long series of individually reasonable decisions that nobody goes back and reconciles.

The question for security leaders across South Asia, Southeast Asia and the Middle East is not whether this debt exists in their environment. It is how much of it there is, and how long it would take to find out.

The clean answer, and the one the environment gives

Ask any IT head how access works and you will get a clean answer. Joiners are onboarded through a process. Roles determine what people can reach. Leavers have their accounts disabled. There is an access matrix somewhere, reviewed at some point.

Now ask the same organisation to list every human and non-human identity that can reach the finance application, with the date each was granted and the person who approved it. The clean answer disappears. What comes back is a set of partial answers from systems that do not agree, assembled over several days by people who have other jobs.

The gap between those two answers is the whole problem. The org chart describes intent. The environment describes what happened. Identity management is supposed to keep the two in sync, and in most organisations it does so for the first couple of years after a directory is deployed, then slowly stops.

Several things cause the drift. Applications are added faster than identity integrations, so a growing share of access lives outside the central system. Business units procure SaaS directly. Mergers, subsidiaries and regional entities bring directories that never fully consolidate. Outsourced IT needs administrative access that no HR system will ever describe. And the people who understood the original design leave, taking the undocumented parts with them.

Meanwhile the regulatory environment moved. India’s DPDP Act, Sri Lanka’s Personal Data Protection Act, Bangladesh’s emerging regime, Singapore’s PDPA, the UAE’s federal PDPL alongside the separate DIFC and ADGM rules, Saudi Arabia’s PDPL and the NCA’s Essential Cybersecurity Controls, and equivalents in Qatar and Oman converge on one expectation: you should be able to demonstrate, not assert, that access to personal and sensitive data is limited to those who need it and revoked when they do not. Central bank cybersecurity guidelines across the region, along with ISO 27001, SOC 2 and PCI DSS where they apply, ask a version of the same question about who had access to what, and when.

None of them care that your identity data is spread across six systems. They ask for evidence, and evidence is the one thing accumulated identity debt cannot produce.

Where the debt actually comes from

The failure is rarely one broken control. It is a set of ordinary patterns, each defensible alone, compounding over years.

• Onboarding runs on a ticket, and access is granted by copying someone

The most common way access is provisioned is not a role model. It is a sentence in a ticket: “please give her the same access as Priya.” The service desk engineer opens Priya’s account, copies her group memberships and application assignments, and closes the ticket. Four minutes instead of forty.

The problem is that Priya’s access is itself a sediment of every project she has been on for six years. She still has rights in a system her team stopped using, elevated permissions from a data migration, and access to a shared folder she was added to for a single audit. None of that is relevant to the new joiner. All of it is now hers.

Do this a few hundred times and entitlement creep becomes a structural property of the environment rather than an occasional exception. Nobody can say what a role is supposed to have, because there are no roles. There are only copies of copies, and the original is long gone.

• The leaver who never fully left

Deprovisioning is the control everyone believes they have and almost nobody has completely. The domain account is disabled on the last working day, because that is the one system the checklist reliably covers. Everything else survives.

SaaS applications procured by a business unit and never integrated with the directory keep their local accounts. The VPN certificate on the laptop remains valid until expiry. A personal API token keeps working, because tokens do not check whether their owner is still employed. Shared mailboxes retain forwarding rules. And the departing engineer knows the shared administrator password, which will not be changed because nobody is certain what would break.

The account being disabled is often taken as proof that the person is gone. It is proof of one thing only: that one account is disabled.

• Contractors, third parties and the outsourced IT team

Across the region, much technical work is delivered by contractors, system integrators and managed service providers. This is efficient and will not change. What it means for identity is that a significant population of privileged users sits entirely outside HR.

There is no joiner record, so nothing triggers structured onboarding. There is no leaver record, so nothing triggers deprovisioning. Access is often granted permanently, because renewing it monthly would create friction with a delivery partner. The engineer who built your data centre network three years ago may still hold the credentials that let him back into it.

The same applies to auditors granted read access for an engagement, vendors given a login to support their own product, and offshore teams whose accounts were created in a batch and never revisited.

• MFA where it was easy, not where it matters

Almost every organisation has deployed multi-factor authentication. Almost none has deployed it uniformly. It went onto email and the cloud productivity suite first, because those had native support and the rollout was easy.

What did not get MFA is the older, more sensitive tier. The finance and ERP application that speaks only its own authentication protocol. The jump host engineers use to reach production. The legacy core system. The database console. Each was deferred to a phase two that has not arrived, and each holds more consequential data than the email that is now well protected.

An attacker who has phished a credential does not attempt the hardened front door. They enumerate what accepts a password alone.

• Privileged accounts shared by four people and a vault nobody rotates

The root account on the production cluster is shared. So is the domain administrator credential, the network device enable password and the database superuser. They are shared because handing every engineer a named privileged account felt like more risk, not less, and because some of these systems do not support individual accounts at all.

The credentials live in a password vault, which was the responsible thing to do. But the vault stores them rather than governing them. The rotation policy exists on paper and has not run in a year, because rotating a credential that four automated jobs also use is a change request nobody wants to own. Sessions are not recorded, so when something changes at two in the morning there is a log entry saying the shared account did it, and no way to say which of four engineers was at the keyboard.

Accountability disappears at exactly the level of access where it matters most.

• Service accounts, bots and now AI agents

Every organisation has service accounts created by a project team, given broad permissions to make an integration work, then left alone because the integration works. Their passwords do not expire, because expiry would break production. Their owners have often left. No HR system will ever tell you one of them should be reviewed.

That population is growing faster than the human one. Automation bots hold credentials to the applications they drive. CI/CD pipelines hold deployment keys. SaaS integrations hold tokens with standing permission. And AI agents are increasingly given the ability to read from and act on business systems, which means identities and entitlements with very little of the governance applied to a human joiner.

Non-human identities typically outnumber human ones by a wide margin, hold broader permissions, and are almost never included in an access review.

• Audit season becomes archaeology

All of this stays out of sight until an auditor, a regulator or a customer’s risk team asks a specific question. Who had administrative access to the payments application in March. Who approved it. When was it last reviewed.

At that point a small team spends two weeks exporting group memberships, cross-referencing them against a spreadsheet of employees, chasing managers for sign-off on a list they do not understand, and reconstructing approvals from email threads. The output is a snapshot that was out of date when it was produced, and it will be rebuilt from scratch next cycle.

This is the real cost of identity debt. Not a breach, most of the time. Just an expensive, recurring reconstruction of information the environment should produce in a query.

Why another identity product does not close the gap

The standard response to an identity problem is to buy an identity product. Weak authentication produces an MFA product. Two years later, password fatigue and application sprawl produce a single sign-on product. An audit finding on privileged access produces a PAM product. A governance requirement produces an access review tool. Each purchase is a rational response to a real finding.

The result is four or five systems, each with its own idea of what a user is.

The directory has one record. The SSO product has a profile that was synchronised at some point and has since drifted. The PAM product has a separate local user, because the engineer who set it up needed it working before the integration was ready. The MFA product has an enrolment list. The governance tool imports from all of them and produces a fourth version of the truth.

Now try to answer a simple question. Has this person’s access been fully removed? Not from any single console. You answer it by checking four and hoping they agree, and they will not, because no shared identifier ties one system’s view of a person to another’s. Reconciling them is a project, repeated every time any of the four changes.

The integration burden also has to go somewhere, and in most mid-market organisations it lands on one or two people. Every point tool needs connectors maintained, versions upgraded, policies configured in its own idiom and its reports interpreted. Organisations that cannot staff a dedicated identity and access management team end up staffing one anyway, informally, out of an infrastructure team that has other work.

Meanwhile the actual gaps stay open. The contractor’s account is still active, because none of the four products was ever told that contractors exist.

How Cymmetri approaches this differently

Cymmetri is a converged identity platform. That word is worth being precise about, because “converged” is often used to describe separately built products sold under one brand.

Here, identity lifecycle management, identity governance, single sign-on with adaptive multi-factor authentication, passwordless authentication and privileged access management sit on a shared identity model. The Identity Hub acts as the single source of truth for users, groups, attributes and access rights across cloud, SaaS, database and on-premises systems. Governance, access and privilege read from and write to that same record rather than maintaining their own.

The practical consequence is the one that matters for identity debt. When you ask whether a person’s access has been removed, there is one place to ask.

1. A lifecycle that starts where the person actually starts

Cymmetri’s lifecycle management is built around provisioning rules, mover rules and deprovisioning rules, driven from an authoritative source rather than a ticket. It integrates with HRMS platforms, Active Directory, LDAP, Azure, Google Workspace, databases, flat-file directories and service desk systems, and supports SCIM 2.0, REST, SOAP and PowerShell connectors for applications with no standard interface.

Mover rules are the piece most environments lack entirely. When someone changes department or role, entitlements can be adjusted to the new position rather than layered on top of the old ones, which is precisely where entitlement creep begins. Deprovisioning rules act on the same triggers in reverse, and the suspended and archived user states let you move an identity through a controlled wind-down rather than deleting it and losing the audit trail.

Reconciliation runs against target systems to find what is actually there, and the 360 degree reconciliation and comparison report exposes accounts the identity system did not create and does not know about. That is how orphaned accounts, including the contractor nobody deprovisioned, become visible.

2. Governance that produces evidence instead of spreadsheets

The governance module runs access reviews and group reviews as campaigns rather than an annual exercise in exporting CSVs. Segregation of duties is enforced as policy rather than discovered after the fact, and role conflicts are surfaced proactively.

Role mining addresses the copying problem directly. Rather than asking a business to design a role model from a blank page, Cymmetri analyses existing user-permission assignments, clusters entitlements, correlates them with attributes such as department, location and designation, and proposes candidate business roles, then removes roles with negligible assignment. This turns years of accumulated sediment into a starting point for least privilege rather than an obstacle to it.

A policy simulator lets you model the effect of a policy change before applying it, which is what makes cleaning up entitlements politically feasible. Compliance management, risk management and dashboards for the CISO and CRO turn the underlying data into reporting rather than requiring someone to assemble it.

3. Access and privilege governed together

Single sign-on supports SAML 2.0, OpenID Connect and API-based integration. Multi-factor authentication covers push, TOTP authenticator apps, SMS, FIDO and secret questions, and can be applied at application level through MFA rules rather than only at the front door. That is what closes the gap between the well-protected email system and the unprotected finance application.

Adaptive authentication adjusts requirements based on context such as location, device, time and application sensitivity. Passwordless options include FIDO, WebAuthn, TOTP, OTP and consent-based sign-in, reducing the credential surface phishing depends on.

Privileged access management is part of the same platform rather than a separate island. Privileged credentials sit in an encrypted vault with automated rotation. Sessions against managed servers and devices are monitored and recorded, including keystrokes and screenshots, which restores individual accountability to shared administrative accounts. Elevated access runs through approval workflows with MFA. Break glass configuration provides a controlled emergency path to vault credentials, and dormancy disable configuration addresses privileged accounts that have simply stopped being used, which is where much standing risk sits.

Because privilege shares the identity model, a leaver is a leaver everywhere. Deprovisioning does not stop at the directory and leave the vault untouched.

4. Humans, machines and AI agents in one control plane

Cymmetri positions its Identity Control Plane as covering humans, machines and AI, securing workforce identities, non-human identities and AI agents through real-time risk detection and policy-driven control. This is the part most identity estates are least prepared for, and the part growing fastest. Service accounts, bots, API integrations and AI agents need owners, entitlement boundaries, review cycles and revocation paths in the same way people do.

5. Deployment that fits regional constraints

The platform is built on a microservices architecture and can be deployed on-premises, in the cloud or in hybrid form. For BFSI, government and healthcare organisations in India, Sri Lanka, Bangladesh, the UAE and Saudi Arabia operating under data residency expectations, that flexibility is not a nice-to-have. It determines whether the project is possible at all.

What this looks like in practice

Consider the same contractor, in an environment where identity is converged.

1. The engagement is recorded as a non-employee identity with a defined end date and a named internal sponsor, not as a service desk ticket.
2. Access is requested against defined entitlements through an approval workflow, not by copying an existing user’s permissions.
3. Privileged access to the servers in scope is granted through the vault. He never holds the underlying credential, and his sessions are recorded.
4. Multi-factor authentication applies to the reconciliation application and the jump host, not only to email, because MFA rules are set per application.
5. At the contract end date, deprovisioning rules revoke application access, remove group memberships and close vault entitlements without waiting for HR, which was never going to file anything.
6. Reconciliation runs against target systems and flags accounts that persist outside the platform, so a local account created during the project does not survive silently.
7. When an auditor asks who had privileged access to that system in March, the answer is a report with approvals, review decisions and session records attached.

No step is remarkable on its own. The difference is that all seven happen in one system, so none depends on a person remembering.

The debt, and the control that answers it

The operational reality	How a converged platform addresses it
Access granted by copying an existing user	Role mining derives candidate roles from real assignments; policy simulator models cleanup first
Leavers whose SaaS accounts and tokens outlive them	Deprovisioning rules from an authoritative source, plus reconciliation reports that surface unmanaged accounts
Contractors and third parties with no HR record	Non-employee identities with end dates, sponsored ownership and workflow-based requests
MFA on email but not on finance apps or jump hosts	Application-level MFA rules and adaptive authentication based on context
Shared privileged credentials, a vault nobody rotates	Encrypted vault with automated rotation, session recording, approvals, break glass, dormancy controls
Service accounts, bots and AI agents nobody governs	An identity control plane covering non-human identities alongside workforce identities
Audit season as manual archaeology	Access review and group review campaigns, compliance and risk reporting, CISO and CRO dashboards

Who benefits most

Mid-market and large BFSI organisations under central bank cybersecurity guidance, where privileged access, segregation of duties and demonstrable access reviews are examined directly and audit findings carry commercial consequences.

Government and public sector bodies with on-premises or data residency constraints, large contractor populations and a need to evidence access control against national frameworks.

Healthcare and telecommunications providers running a mix of modern SaaS and long-lived legacy systems, where sensitive data sits in applications never designed for federated authentication.

Organisations that outsource IT to system integrators and managed service providers, and any organisation growing faster than a two-person infrastructure team can service.

EGUARDIAN distributes Cymmetri across its territories in South Asia, Southeast Asia and the Middle East, and works with channel partners on scoping, proof of concept and deployment.

The real question

Identity debt is not a security problem that happens to involve operations. It is an operational problem that eventually becomes a security problem, and in the meantime it is a cost problem, an audit problem and a trust problem.

Every organisation carries some. The question worth asking your team is narrower than whether controls exist on paper: if a contractor finished a project eighteen months ago, what would tell you their access is still live, and how long would it take to find out?

If the honest answer is that nothing would tell you, that is not a failure of diligence. It is what happens when identity is managed by four systems that do not agree, or by one that only ever saw part of the picture. It is fixable, and worth fixing before an auditor or an attacker does the discovery for you.

Talk to our experts at EGUARDIAN. If your environment is carrying identity debt you cannot fully see, and you have no dedicated IAM team to work through it, let us work through what you are running, your regulatory obligations and what a converged approach would look like for your organisation. Reach out to us at hello@eguardian.com.