The Identity Provider as a Discovery Source

If you have single sign-on, your identity provider already holds the best inventory in the organisation. Most programmes underuse it.

What to extract

The application list, with configuration dates.

Assigned users per application.

Authentication events, which give real usage rather than assigned seats.

Last successful sign-in per user per application. The single most valuable field for licence work.

Failed and blocked attempts, which occasionally reveal applications people are trying to use.

Application owners, where the platform records them.

What it tells you immediately

Assigned but unused. Users with access who have not authenticated in months. This is the licence saving, and it is available on day one.

Applications with very few users, which are candidates for consolidation or retirement.

Applications with no recent authentication at all, which are being paid for and not used.

Users with access to unusually many applications, which is an access review question.

Applications configured and never rolled out, which happens more than expected.

Where it misleads

Assigned is not licensed. Your identity provider knows who can sign in, not how many seats you bought. The two diverge, and the licence count lives in the vendor's admin console or the contract.

Some applications authenticate without going through your provider for a subset of users — local admin accounts, service accounts, legacy logins. These are invisible here and they are frequently the privileged ones.

Usage is authentication, not activity. A user who signs in once and does nothing looks active.

Applications behind a portal may show a single sign-in for a session covering several tools.

Deprovisioning may lag. A user removed in your directory may retain a local account at the vendor, which is the core offboarding failure covered separately.

The federation gap

The most important limitation, and the one to measure.

Compare the SSO application list against your expense data. The applications appearing in one and not the other are your gap.

Applications not federated are the higher risk ones, systematically: local passwords, no central deprovisioning, no visibility.

Federating more of the estate is the single highest-return technical action in a SaaS programme. It improves discovery, offboarding, access review and security simultaneously.

Track the federation rate — proportion of known applications behind SSO — as a programme metric. It is objective, it improves with work, and it correlates with everything else getting easier.

Practical extraction

Most identity platforms expose this by API and by scheduled report.

Pull monthly into your register, matched on application.

Keep the history. Usage trends over quarters answer questions a point-in-time export cannot, particularly at renewal.

Watch for application name changes in the provider, which break the join silently.

The renewal use

The strongest single application of this data.

Before any renewal, pull last-login for every assigned user.

Count how many have not signed in during the term.

That number is your negotiating position and your seat reduction, and it takes minutes to produce.

Organisations that do this consistently reduce seat counts at renewal by a meaningful margin, every year, on data they already had.

The federation backlog

Turning the federation gap into a work queue rather than an observation.

List applications not behind single sign-on, from the comparison against expense data and the register.

Rank by users first, then by data classification. An unfederated application with two hundred users is a bigger offboarding hole than one with three.

Check which ones support federation and at what tier, since some vendors place it behind a premium plan.

For those that support it: schedule the work, a few per quarter.

For those that do not: record them as a permanent exception, ensure deprovisioning is on the offboarding checklist explicitly, and factor it into any replacement decision.

Track the federation rate monthly. It is the single metric that best predicts whether the rest of the programme will be easy or hard.

Reading last-login carefully

The most valuable field in discovery data, and the one that most reliably produces wrong conclusions when read naively.

Authentication is not activity. A user who signs in daily and does nothing appears fully active.

Session length varies. Some applications hold sessions for months, so a recent login may be a year old in practice.

Integration usage may not authenticate, so a heavy API consumer looks dormant.

Mobile applications frequently maintain long-lived tokens.

Prefer the vendor's own activity data where it exists — actions taken, documents opened, records changed — over authentication events from your identity provider.

Where only authentication is available, use it as a screening tool and confirm with the owner before acting, which is the process described in the unused-licences note.