TL;DR Every identity vendor now sells a “platform.” Many are acquired products sharing a logo. Five questions on policy, audit, deployment, incident response and expansion tell you which one you are buying before you sign.
In February, a $25 billion deal closed: a network-security giant bought out one of the biggest legacy PAM vendors. By May, the acquired portfolio had a new name and a new promise: a centralized control plane for human, machine and agentic identities.
The rest of the identity market is heading the same way. The big workforce-identity providers sell their stacks as platforms, and so does nearly every PAM vendor. Buyers are tired of running six identity tools, and vendors have started to take notice.
But a shared logo and a shared login page are not a shared architecture. One brand makes governance and reporting tidier, yet each product underneath can still carry its own deployment, its own configuration and its own operational overhead. The launch coverage leans on the control plane and the upgrade path for existing customers. It says far less about how much of the stack underneath is actually one.
That isn’t a scandal. It’s what happens when a platform is assembled from acquisitions, and it describes a good part of this market. The buyer’s question is simpler: are you buying one system, or four products standing on each other’s shoulders under a long coat?
Here are five questions that tell you which, before the renewal invoice does.
1. If I write one access rule, how many places do I configure it?
Take a rule your auditors actually care about: contractors get no standing admin rights anywhere; elevation is just-in-time, approved by their manager, and expires after four hours.
On a real platform, that rule is written once and enforced across vault access, endpoint elevation, cloud entitlements and app sign-in. On a bundle, you write it in the PAM console, again in endpoint privilege management, again in the cloud entitlements tool, and hope a sync job keeps them consistent.
Ask the vendor to demo the rule end to end. Then ask what happens when two of those policies disagree. If nobody can answer without checking with another team, you have your answer.
2. Can I see everything one identity did, in one timeline?
Pick an identity—a departed engineer, a service account, or an AI agent with API access. Now try to audit everything it did yesterday: every credential checkout, privileged session, local admin elevation, entitlement change, and app launch.
One search is great. But if the reality is "export from every module and correlate in the SIEM," you’ll be fighting to join disparate data tables in the heat of an incident. You shouldn't be normalizing three different timestamp formats and mismatched IDs while the clock is ticking. Attackers thrive in those exact gaps. A stolen service account credential doesn't care about your logging silos.
3. How many installers, databases and upgrade calendars am I signing up for?
Ask for the deployment architecture diagram and the version compatibility matrix. Count the servers, connectors and databases.
If a compatibility matrix exists at all, that’s a clue. Modules that ship from one codebase don’t need a chart explaining which versions can talk to each other.
This matters most on-prem and in private cloud, where your team owns every upgrade. Six products mean six patch cycles, six sets of release notes and six chances for an upgrade to break an integration nobody owns.
4. How many consoles does my on-call engineer open at 2 a.m.?
Run a tabletop exercise. A service account’s credentials just surfaced in an infostealer dump. Your engineer has to triage the blast radius immediately: revoke its access, rotate the secret everywhere it’s hardcoded, kill live sessions, audit its cloud entitlements, and verify that no downstream AI agents were borrowing it. Now, count the browser tabs.
Count the logins. Every separate console forces you into a different admin account, a different role model, and a different MFA workflow. That means your identity security stack is just creating more privileged identities you have to protect. More consoles mean a longer checklist and a slower response. In an identity incident, the clock is measured in minutes—and yours is ticking.
5. What happens when I buy one module now and add another next year?
Few teams buy a full identity stack all at once. They start by firefighting the most urgent problem—vaulting, MFA, or endpoint privilege—and plan to expand later.
So ask the hard question: Is adding the next module as simple as activating a license key on your existing instance? Or is it a net-new project requiring a Statement of Work, fresh servers, another user re-import, and a ground-up policy rebuild? Ask the vendor exactly how many months it takes for module number two to go live for a company your size.
On a true platform, the second product deploys faster than the first because your identities, policies, and directory connections are already built. On a marketing bundle, every expansion is just a fresh, painful deployment wearing the same corporate badge.
What a platform actually looks like
A platform isn’t a product count. It’s what stays the same when you add products: one codebase, one console, one audit trail, and one place where every identity, human, machine or AI, is defined once and governed everywhere.
That’s why acquisition-built suites find this hard. Bolting a control plane onto separate codebases is an integration project that never really ends. Building one from the first line of code is a different engineering decision altogether.
It’s the decision we made at Securden. PAM, endpoint privilege management, IGA, CIEM and AI agent security are built on a single codebase, ship as a single installer and run from one unified dashboard, so human, machine and AI identities are governed in one place instead of five. Teams can start with the module they need most and switch on the next in the same instance, which is a big reason our customers go live 50–60% faster. If you want to see the five questions answered without the trench coat, start at securden.com.