Understanding account administration comparison properly

Almost every comparison in this category is really the same comparison: the directory you already own against a dedicated one somebody has quoted for. Framing it as a survey of the market wastes a month. The incumbent is not going away, and the challenger has to beat it rather than merely be good.

So this page is about running that comparison honestly, including the part where the incumbent gets an unfair advantage from familiarity and the challenger gets an unfair advantage from a demonstration.

What to take away

The coverage matrix

This is the artifact that decides most comparisons, and it takes an afternoon.

List every system that holds accounts down the left. Across the top, put the four capabilities that matter: central sign in, automatic provisioning, automatic removal, and an access record. Then fill it in for the incumbent and again for the challenger, marking each cell as yes, no, or only on a higher tier.

Two numbers fall out. How many systems gain something under the challenger, and how many gain nothing under either. The second number is the one people avoid looking at, and it is often large, because it holds the old finance package and the supplier portal that will never connect to anything.

If the challenger improves twelve systems and eight remain untouched, you now have a proportionate decision rather than an argument about features.

The protocol trap

A product that lists a standard sign in protocol is telling you what it can speak, not that it works with your particular application at your particular version. Compatibility in this category is a property of a pair.

Test the pairs that matter. Connect your three most important systems during evaluation instead of accepting a compatibility list, and watch for the three usual problems.

The application supports the protocol only on an edition you do not have, and the connection works for sign in but not for creating or removing accounts. Group membership does not carry across, so access still has to be managed in the application.

The third is the most common and the most disappointing, because it means you get single sign on without getting central access control, which is half the benefit and most of the price.

Compare the model, not the vocabulary

Products in this category describe similar arrangements in different words, and the marketing vocabulary changes faster than the architecture does. It helps to have one stable frame to translate into.

The published description of a zero trust architecture is useful for that, not as a purchase target but as vocabulary. It names components, including the decision point and the enforcement point.

Ask each supplier which of those they are and which they expect you to already have. Half of a confusing comparison resolves once you know that one product is a decision point; the other is a decision point plus enforcement.

What happens when it breaks

Put the same three scenarios to both candidates, in writing, and compare the answers rather than the reassurances.

A person is locked out with the second factor on a phone that is now in a river. Describe the path back in, who is involved, and how long it takes. The identity system itself is unavailable for four hours.

Which systems still work, which fail closed, and is there a documented way back in that does not depend on the product. And an administrator account is compromised. What can be done from the console before anyone notices, and what would appear in the record afterwards.

These questions separate products more than feature tables do, and they separate suppliers even more. The principles used to assess cloud services generally are a reasonable checklist for the second scenario. The cloud security principles put resilience and separation in terms you can put to a supplier without a specialist.

Scoring the incumbent fairly

The directory you already run has two advantages that are genuine and two that are illusions.

Genuine: it is already connected to things, and your people already know it. Both are worth real points, because a migration in this category is disruptive in a way that ordinary product moves are not, and the cost of retraining administrators is not small.

Illusory: it feels safer because nothing has gone wrong yet. Its limits are invisible because you worked around them.

Counter both: write the incumbent's requirements sheet as if buying fresh, then score it against the coverage matrix like any other candidate. Bad scores on your requirements are information, not disloyalty. Score both with the feature questions.

Breaking the tie

If both clear the requirements, decide in this order.

Consider what the estate looks like in three years, since this layer is long lived and switching cost only grows, then the recovery path, which you will use most often. Then cost, using the model in the pricing notes, not the headline.

Preference comes last, but still record it: a console administrators dislike gets used less carefully.

Write five sentences on the decision, including what you gave up. Renewal is much shorter when the earlier reasoning exists on paper.

Where this fits

The category overview covers what this layer is for. The evaluation drill is the timed test to run once the matrix has narrowed the field, and the cheaper arrangements are worth revisiting if the matrix shows the challenger improving fewer systems than expected.

Common questions

Should we compare more than two options?

Rarely. The incumbent plus one serious challenger is the real comparison. A third is useful only if the first two both fail a requirement, in which case the requirement deserves rechecking too.

How long does a proper proof of concept take?

Two to three weeks, with three real applications connected and the failure scenarios rehearsed. Less than that and you have tested the sign in page. More than that and you are usually avoiding the decision.

Can we compare on price alone if both meet the requirements?

You can, provided the requirements list is honest and includes the record retention period and the connectors by name. Price comparisons go wrong in this category because the cheaper option meets the requirements on a tier that does not include the connector list.

What if the challenger is clearly better but the migration looks painful?

Then price the migration properly and put it in the comparison as a line rather than as a feeling. Identity migrations are genuinely disruptive, and a challenger that is better by a small margin usually does not justify one. A challenger that answers a question you currently cannot answer at all usually does.