Every vendor in these three categories will tell you their category is the foundation the other two sit on. All three arguments are internally consistent, which is what makes the decision hard.
The way out is to stop asking which is most important and start asking which failure you can already prove.
The short answer
Buy against evidence you already hold.
Identity governance first if you have repeat audit findings on access review, manual certification campaigns, or a deprovisioning window measured in weeks. The evidence is in the audit report and the case writes itself.
Privileged access first if standing administrative credentials exist in production, shared admin accounts are in use, or you cannot answer who used a privileged credential last Tuesday. The evidence is a query you can run this afternoon.
Identity threat detection third, in most cases. Detection on top of ungoverned entitlements produces alerts about access that should not have existed, and the remediation for every one of them is a governance action you were not resourced to take.
What the vendors in each category will tell you
Predicting the pitch is useful, because each one contains a true statement doing misleading work.
Governance vendors will say identity is the new perimeter and you cannot secure what you cannot see. True, and it argues for visibility rather than for their product specifically. Ask what share of your applications their connectors actually cover, by name, before anything else.
Privileged access vendors will cite the share of breaches involving credential abuse. Also true, and it conflates initial access with lateral movement in a way that flatters the category. Ask specifically about workload and non-human credentials, which is where the population actually is.
Detection vendors will show you an attack that governance would not have prevented. True, and the relevant question is what their product does about it that your existing analytics platform does not. Frequently the honest answer is content rather than capability, and content can sometimes be bought without the platform.
None of these are dishonest pitches. Each is a correct observation aimed at a conclusion that happens to be a purchase order.
Why the obvious answer is wrong
The obvious answer is to buy detection first, because detection feels like security and governance feels like paperwork.
The problem is what happens to the alerts. Identity threat detection flags anomalous use of an entitlement. If entitlements are ungoverned, a large share of those alerts are describing legitimate use of access that nobody should have had, and the analyst investigating cannot tell the difference. The team learns within a quarter that the tool is mostly wrong, and it joins the list of controls that fire into a channel nobody reads.
There is a second version of the mistake that is more expensive. Some organizations buy governance and detection together, on the reasoning that they are complementary. They are, eventually. But a governance rollout takes four to six quarters before the entitlement data is clean enough to be a useful baseline, and detection bought at the start of that window spends its first year producing noise against dirty data, then comes up for renewal before it has ever worked properly.
The discriminating variables
What does your last audit report say?
The test: count the identity findings and sort them. Access review and deprovisioning findings point at governance. Privileged credential findings point at privileged access management. This is the cheapest signal available and most teams do not use it, because the audit report is filed rather than read.
Can you answer the Tuesday question?
The test: who used an administrative credential on production last Tuesday, and what did they do? If the answer takes more than an hour to produce, privileged access is the gap regardless of what the audit said.
How dirty is the entitlement data?
The test: pick one business application and try to produce a list of who has access and why. If the why column is empty, detection has no baseline to work from and buying it now wastes the first renewal cycle.
Is there a regulatory date?
The test: do DORA, NIS2, or a sector regulator put a dated obligation on access control for you? A date reorders everything else, and it is the one input that should override the evidence test above.
What each category actually buys you
The category names are vendor language and they obscure what you are purchasing. In outcome terms:
Identity governance buys evidence and reversal. It produces the record that access was approved, reviewed, and removed, and it gives you a mechanism to take access away at scale. It does not prevent anything. Its value is realized at audit time and during offboarding, which is why its business case is almost always a finding rather than a threat.
Privileged access buys blast radius reduction and attribution. It shrinks the window in which powerful credentials exist and tells you who used them. Its value is realized during an incident, which means it is bought on severity rather than on frequency, and that is a harder budget conversation with a cleaner argument behind it.
Identity threat detection buys time. It shortens the gap between an identity being misused and someone noticing. Its value depends entirely on the quality of the baseline it is comparing against, which is why sequence matters so much for this one specifically.
Read that way, the sequencing argument becomes almost obvious. Evidence and reversal are prerequisites for the other two being meaningful. Blast radius reduction is worth doing whether or not you can detect anything. Detection without a baseline is an expensive random number generator.
The overlap nobody accounts for
Before running any evaluation in these three categories, check what you already own. This is the platform-absorption case and in identity it is unusually large.
Modern identity provider tiers routinely include access certification, lifecycle automation with connectors, some privileged session controls, and identity-specific anomaly detection. Cloud providers include their own privileged access controls and entitlement analysis for their own estate. Your endpoint or security analytics platform may already carry identity detection content.
I have seen an organization run a nine-month identity governance evaluation and then discover that the tier they were already paying for covered the two use cases that actually generated their audit findings. Nobody had read the licence entitlement in three years, which is completely normal and completely avoidable.
The check takes an afternoon: pull your current licence entitlement, list what it includes, and map it against the failure you are trying to fix. Do that before the first vendor call, not after the third.
The question underneath all three
Strip the categories away and every one of them is answering the same question in a different tense: who has access to what, and should they.
Governance answers it in the past tense, as evidence. Privileged access answers it in the present tense, by controlling the moment access is used. Detection answers it in the continuous tense, by watching for use that does not fit.
That framing is useful in a budget conversation because it explains why the three are not substitutes and why buying all three at once rarely works. It also explains the sequencing: you cannot meaningfully watch for access that does not fit until you can state what fitting looks like, and stating that is what governance produces.
Decision table
| What you can already evidence | Buy first | Why |
|---|---|---|
| Repeat access review findings | Identity governance | The finding is the business case |
| Standing production admin credentials | Privileged access | Highest severity per incident, smallest scope |
| Shared admin accounts | Privileged access | Attribution is the prerequisite for everything else |
| Deprovisioning measured in weeks | Identity governance | The clearest audit and offboarding risk |
| Clean entitlement data, governance mature | Identity threat detection | The baseline exists, so detection can work |
| A dated regulatory obligation | Whatever the obligation names | The date overrides the evidence test |
The order most programs actually end up in
Worth naming the common real-world sequence, which is not the ideal one and is often defensible anyway.
Most organizations arrive with an identity provider already deployed, because somebody bought it for single sign-on years before there was a security function. That is the foundation whether or not anyone chose it deliberately.
The second purchase is usually privileged access, and it is usually triggered by an incident or a near miss rather than by planning. This is a reasonable place to land: the severity argument is easy to make after an event, and privileged access delivers value without depending on anything else being clean.
The third purchase is governance, and it arrives when the audit findings stop being tolerable. By this point the entitlement data has had several more years to decay, which makes the governance rollout longer and more expensive than it would have been first.
Detection arrives fourth if at all, usually as a feature of something else rather than as a standalone purchase.
If that describes you, the useful question is not whether the sequence was right. It is whether the governance work is being scoped against the findings you actually have or against a vendor's maturity model. Findings-scoped governance projects finish. Maturity-model-scoped ones become the thing your successor inherits.
What changes the answer
A recent identity incident. After a real credential compromise, detection gets funded whether or not the sequence supports it. The useful move is to accept the funding and scope the detection narrowly to the attack path that actually occurred, rather than deploying broadly against dirty data.
A small organization. Under a few hundred employees, the identity provider's own governance and privileged features frequently cover enough of all three that buying any dedicated product is premature. Check what your existing licence tier already includes before running an evaluation; this is the platform absorption case and it is the most commonly missed source of budget.
A cloud-native estate with few humans. If the population is mostly workload identity rather than employees, the entire framing changes and the governance question becomes the non-human identity question instead.
Buying two at once
Occasionally the right answer, and worth knowing when.
It works when the two purchases are genuinely independent: privileged access and governance touch different populations and different processes, and a well-resourced team can run both without the second waiting on the first. If you have the people and the budget, doing them in parallel saves a year.
It fails when one depends on the other's data, which is always the case for detection. Detection bought alongside governance spends its first four to six quarters producing alerts against entitlement data that is still being cleaned, and comes up for renewal before it has ever had a fair test.
The practical rule: parallel is fine for governance and privileged access, never fine for detection plus anything. And be honest about the people. Two simultaneous identity rollouts is two programs, and if the same person owns both, you have sequenced them anyway, just without admitting it.
What to do Monday
Open the last audit report and count the identity findings by type. Then run one query: list every account with standing administrative access to a production system.
Whichever of those two exercises produces the more uncomfortable result is your first purchase. That is a lower-effort decision procedure than any vendor evaluation, and it is better evidence than any of them will give you.