SailPoint to Acquire Entro

The price is the least interesting part of this deal. For twenty years, identity governance has meant human identity governance: joiners, movers, leavers, access certification, segregation of duties. Machine identities were someone else's problem, which in practice meant nobody's. SailPoint buying Entro is the clearest signal yet that the major governance vendors now intend to treat a service account with database admin rights the same way they treat a human with database admin rights: inventoried, owned, reviewed, and switched off when no longer needed.

What Entro actually does

Entro sits in the category the industry has settled on calling non-human identity security, or NHI. The product does three things that matter.

First, discovery. It scans the places secrets actually live: dedicated vaults, cloud secret stores, code repositories, CI/CD pipeline variables, and the collaboration tools where developers paste keys when they are in a hurry. That last one matters more than most security teams want to admit.

Second, context. Finding a key is easy; knowing what it is takes work. Entro maps each secret to the identity behind it: what it can access, who created it, when it was last rotated, whether it has turned up somewhere it should not be. That context is what turns a list of ten thousand strings into something a security team can act on.

Third, monitoring. A token that has behaved the same way for a year and suddenly starts querying new resources from a new location is a story worth investigating, and it is exactly what abuse of a stolen machine credential looks like in practice.

The reason this is a product category rather than a feature is scale. Machine identities outnumber humans many times over in any organisation that builds software or automates operations. Every microservice, every scheduled job, every integration between two SaaS platforms, every RPA bot carries at least one credential. Almost none of them go through a joiner-mover-leaver process.

The gap SailPoint is buying its way out of

SailPoint's platform is built around the human lifecycle. Identity Security Cloud, and IdentityIQ before it, are good at provisioning a new employee, moving access when someone changes roles, running certification campaigns, and flagging toxic combinations of entitlements. That machinery has never touched the service account a developer created five years ago for a data extract that still runs every night.

SailPoint knows this, and had already started shipping machine identity features on its platform before this deal. The difficulty with governing machine identities from a governance platform is that governance assumes you know what exists. Humans arrive through HR feeds. Service accounts arrive through nothing: they appear in a pipeline, a cloud console, a vendor integration. Without a discovery layer, machine identity governance is certification theatre. You cannot review access you have never seen.

That is the specific hole Entro fills, and it is why the acquisition makes more sense than a feature-list comparison suggests. SailPoint is not buying a vault or another lifecycle engine. It is buying the layer that tells the lifecycle engine what exists and who should answer for it.

The honest caveat: acquisitions integrate slowly. Two platforms, two data models, two engineering cultures. The sensible planning assumption is that meaningful integration lands in Identity Security Cloud first, and that on-prem IdentityIQ estates, which is what a fair share of regional deployments still run, see little for some time.

What changes for UAE and GCC buyers

SailPoint has genuine presence in the region, particularly in banking and government, and that is exactly where the machine identity problem bites hardest.

When examiners or ISO 27001 auditors ask for access control evidence, most UAE enterprises can produce it for humans: review campaigns, approval records, leavers disabled on time. Ask the same questions about service accounts and the room goes quiet. In my experience the service account question is where regional access review programmes fall over: no named owner, no rotation date, and nobody willing to switch anything off because nobody knows what will break. Assessors have noticed, and they increasingly expect a machine identity inventory with named owners and rotation evidence, not a policy document that says rotation happens. The identity and IAM questions I hear from regional teams have shifted in exactly this direction.

Will this deal change anything on the ground soon? No. What it changes now is procurement. If you are evaluating identity governance platforms this year, non-human identity coverage belongs in the scoring matrix, weighted for what ships today rather than what a roadmap slide promises.

Where this collides with PAM

The awkward overlap is privileged access management. PAM vendors have claimed secrets management for years, and if you run a mature deployment from a vendor like BeyondTrust, part of this story sounds like something you already own.

The honest distinction: PAM governs the credentials you put in the vault. NHI tools find the ones nobody vaulted: the key hard-coded in a repository, the token sitting in a pipeline variable, the service account created outside any process. One manages known privileged credentials well; the other maps the unknown ones. They are complementary in architecture and rivals in budget, so expect both camps to fight over the same line item in next year's plan.

If your privileged access management programme is mature, the incremental question is discovery coverage, not another vault. If you have neither, PAM for your known administrative accounts is still the first purchase, because that is where a single compromised credential does the most immediate damage.

What to do before the integration ships

Do not buy an announcement. Deals get reported, then close, then integrate over quarters. Score what a vendor can demonstrate this quarter.

The useful work needs no purchase order. Pull the service principals and app registrations from Entra ID, the service accounts from Active Directory, the IAM roles and access keys from your cloud accounts, and the credentials referenced in your pipelines. Put them in one list. Assign each one a named owner. In my experience the first pass finds a meaningful share of machine identities that no team will claim, and unclaimed almost always means unrotated and unwatched. Disable the orphans in a controlled window and see what complains.

For teams with a SailPoint estate, the questions for the account team are direct:

• What does Entro integration look like in Identity Security Cloud today, demonstrated live, not on a roadmap slide?
• Is it licensed inside existing tiers or as a separate line item?
• What is the plan for IdentityIQ on-prem customers?
• Which discovery sources are covered: which vaults, which repositories, which cloud providers, which collaboration tools?
• How do certification campaigns handle an identity whose owner is a pipeline rather than a person?

The acquisition is a rational move and probably a good one. But machine identity is an operating-model problem before it is a tooling problem. Someone in your organisation has to own each service account, answer for what it touches, and retire it when its job ends. No vendor, acquired or acquiring, can do that part for you.