Not a coordinated announcement. Not one big FinOps push. A steady drip of native cost controls, one vendor after another, all landing between June and August. Once you notice the rhythm, the rhythm is the story.

Who’s building the meter?

The people who sell the tokens.

Count the native spend controls across the major model-and-cloud vendor surfaces this summer, one per surface, and you get five. OpenAI added them to ChatGPT Enterprise on Jun 18. Anthropic shipped an Enterprise Spend Limits API for Claude on Jul 2. OpenAI brought hard project and org limits back to its API on Jul 22. AWS added cost controls to Bedrock AgentCore on Aug 6. Google shipped hard monthly spend caps to Gemini Enterprise on Aug 26.

Five, from Jun 18 to Aug 26. About ten weeks. Same season, same handful.

The exact count is soft, and I’ll say so. The inclusion rule is strict: one native spend control per major model-or-cloud vendor surface. Loosen it and the number goes up, not down. Anthropic shipped a session-budget control too. GitHub Copilot added budgets. Cloudflare’s AI Gateway has spend controls of its own. Count those and the cadence gets faster, never slower.

So the ordinal is a footnote. The cadence is the fact: the companies whose revenue is the meter running spent the summer building the switch to cap it.

Are these even the same kind of control?

No. There are two philosophies.

Anthropic and AWS bound a run. The limit sits on a session or a per-agent execution, and it fires when a single agent burns through its budget mid-task. OpenAI and Google bound a billing period. The limit is a monthly cap on the project or org, and it fires when the bill for the month crosses a line.

Bound-the-run versus bound-the-billing-period. Same anxiety, an agent doing something expensive when nobody’s watching, and two bets on where to put the brake. One vendor thinks the danger is a single runaway execution. The other thinks it’s the slow accumulation over thirty days.

What both bets share: each brake stops at the vendor’s own wall. AWS can cap a Bedrock run because AWS can see the Bedrock run. It cannot see the Gemini one. Google can cap a Gemini project because Google bills it, and has no idea what that same team spends on Claude.

Did all five vendors freshly build these?

Not quite. At least two are re-ships.

This is the tell worth slowing down on. OpenAI’s Jul 22 API control isn’t new. OpenAI had hard API spend caps, removed them earlier in 2026, and brought them back on Jul 22. Its Jun 18 ChatGPT Enterprise control isn’t net-new either. It’s a migration of an existing weekly limit to a monthly one. Anthropic, AWS, and Google are genuinely net-new to those surfaces. OpenAI, on two of the five, is adjusting a meter it already had.

That’s the part a pundit reading only the August release notes can’t write. Picture OpenAI shipping the hard cap, quietly removing it earlier in 2026, then reinstalling it in July and taking a bow for the new safety feature. A seller that can pull a hard spend cap and put it back whenever it suits the billing is telling you something plain: the meter isn’t a fixed customer-protection feature. It’s a dial the seller turns toward its own billing interest, on its own schedule. Which is exactly why a seller-built meter can’t be the buyer’s number. The buyer doesn’t control when it exists.

So the meter-builders are marginal players you can ignore?

The opposite. They’re already everywhere.

The same handful shipping these caps already sit in nearly every stack we see. OpenAI and Anthropic each show up in about 96% of those stacks, Gemini in about 82%, detected via SSO, finance, and browser extension, so read those as detection floors, not exact usage.

One clause of daylight, because it matters. That presence is of the brand. We detect that OpenAI, Anthropic, and Google are in the building. We are not detecting use of the specific agent or API surface each cap governs, the Bedrock AgentCore workload, the Vertex or Gemini Enterprise project, the raw OpenAI API. Presence is not proof the cap already binds anything. It establishes the one thing the argument needs: the vendors writing the meters are not niche. They’re the default.

And when the top work surface joins the cadence, the signal is loudest. Google Workspace is already the #2 app in our Adoption Index, ahead of Slack, Atlassian, and Microsoft 365, and that’s behavioral adoption, where work happens, not a spend ranking. So when that vendor ships a spend cap, it’s the surface most of your people already live on adding a meter.

What’s the actual problem with five good meters?

They’re bounded. Every one of them.

This is the whole thing, and it’s an argument from how the controls are scoped, not a number we measured. Each of the five caps is scoped to something the vendor bills: a project, a billing account, an API key, an org. That’s correct engineering. A cloud vendor should let you cap a project. Nobody built a bad meter here.

But name the dichotomy the scoping creates. Per-vendor wall versus cross-vendor question. Every shipped control is bounded by one vendor’s billing surface. The buyer’s real question crosses all of them and lands on a person: what does this employee cost across OpenAI, Claude, and Gemini, added up. None of the five meters can answer that. None can see the other two, and none was built to join spend to a named human.

I’ll concede the near miss, because it’s real. Cross-vendor cost aggregation already exists. CloudZero, Vantage, and Finout roll up multi-vendor spend, typically drawing on the vendors’ own Cost APIs. What none of those produce, and what the key-, project-, and account-scoped meters structurally can’t produce, is the join to the individual: what one named person costs across every model they touch. The aggregators sum accounts. The meters cap projects. The gap is specifically the human.

And a buyer went looking in exactly that gap. One prospective buyer deprioritized the entire SaaS-governance category to ask us a single thing: what does each employee cost in OpenAI, Claude, and Gemini tokens, across all three. Five vendors spent the summer shipping per-vendor meters. A buyer walked in asking for the number that lives between them.

So who wins?

Genuinely unresolved.

Two candidate units of account, and I don’t know which one takes over. There’s the vendor’s per-project billing meter: native, scoped, shipping fast, five deep in one summer. And there’s a cross-vendor, per-employee view of what each person costs across every model they touch, which nobody ships natively and which the buyer keeps asking for.

Maybe the per-project meter is enough. For a lot of orgs it might be, and the cross-vendor per-employee view stays a nice-to-have that never becomes the unit anyone budgets against. Or maybe the number that decides headcount and tooling is the one that crosses every wall and lands on a person, and the vendor meters end up as five inputs to a join none of them will ever make.

The vendors have placed their bet: the meter they own, scoped to the surface they bill. The open question is whether that’s the unit the buyer ends up managing by. And if it isn’t, who ends up owning the number that crosses all five walls.

An engineer leaves. IT does what it always does: disables the account in Okta, pulls the SSO grants, reclaims the laptop. On paper, the person is gone.

In practice, the Slack bot they wired to a shared channel is still posting. The Zapier connection they authorized still moves data between two apps every night. The AI agent they handed a service account to still has its access, and nobody remembers it exists.

None of those were tied to their SSO login. They were separate credentials, OAuth grants, integration tokens, an agent’s key, created directly against the apps. Deprovisioning a person doesn’t touch them. So the tokens sit there. No owner, no review, no expiry. Live.

That is the gap offboarding misses. You can revoke a person cleanly and still leave a trail of working machine identities behind them. The customers we hear from already have names for what that produces:

“orphaned after projects end,”

“service account sprawl,”

“invisible, ungoverned, and overprivileged”.

How bad is the sprawl, really?

Bad, and worse than anyone can agree on.

Non-human identities now outnumber human ones by a wide margin, and the count is climbing fast. But the exact ratio depends entirely on what you measure, and where. Different vendors offer widely different counts on how many NHIs are running through your org:

So the number is contested. Different vendors measure different environments with different methods, and the spread, 17:1 to 144:1 depending on the study, reflects that, not sloppiness. What none of them argue about is the direction. The non-human surface is now the larger one, AI agents are its fastest-growing slice, and it is compounding. Read 144:1 as the ceiling of a range, not a consensus.

So why can’t your SSO see any of it?

Because it was built to find people, and none of these are people.

Your SSO and IdP are built around people. They govern who a human is, what groups they belong to, what they can log into. Most identity tooling does that work, and does it well. That part is genuinely hard.

Here’s where it gets uncomfortable. It’s a human-identity model in a world that has gone non-human. When CyberArk surveyed the field, 88% of organizations defined only human users as privileged. The machine identities, the OAuth grant one SaaS app holds against another, the integration token, the Slack bot, the MCP server an agent runs through, never touch the IdP at all. They were provisioned directly, app to app. So when the IdP deprovisions a person, it reaches everything that person logged into and nothing they authorized on the side.

The industry conversation points the wrong way, too. Most writing about machine identity is cloud- and infrastructure-first: workload identity, Active Directory service accounts, secrets in a CI pipeline. That matters. But it steps right past the SaaS-app layer, the OAuth grants, integration tokens, bot tokens, and agents that live between the apps your company actually runs on. That layer is where a departing employee’s leftovers pile up. It is also the one nobody has claimed.

What does governing these things at the app layer actually take?

The same three things you already give a human account.

None of this needs another vault or another scanner. Treat every token and agent at the SaaS-app layer the way you already treat a person: give it an owner, watch it for staleness, wire it into offboarding.

Owner. The first question about any machine identity is the one nobody can usually answer: who created this, and who is accountable for it now? A token with no owner is a “decommission candidate,” in a customer’s own words. Attach a human owner to each grant and agent, and an anonymous credential becomes something you can review.

Staleness. Is it still doing anything? “Hasn’t authenticated in six months but still has privileged access” is how one practitioner named the exact failure. Last-use data sorts the tokens that earn their access from the ones that are pure standing risk.

Offboarding trigger. When a person leaves, their machine identities should surface as part of the same offboarding, the bot they built, the token they authorized, the agent they stood up. Then those credentials get a decision, instead of defaulting to “left running.”

This is where Torii sits. Our SaaS discovery already maps the app-to-app graph; it can see the OAuth grants and integration tokens between apps and attach a human owner and an offboarding trigger to each one. Visibility, ownership, and a trigger at the point of offboarding.

The data itself is not sitting in cold storage somewhere. Productiv’s site states that “all production systems, data stores, and backups have been permanently and securely destroyed. No customer data has been retained.” Productiv has never given a business reason for the shutdown.

One clarification, since the situation has been described loosely elsewhere: this was not a conventional bankruptcy. The public record shows that, effective June 25, 2026, Productiv, Inc. made a General Assignment for the Benefit of Creditors to PFS Productiv Liquidation LLC under California law, a state-law wind-down handled outside bankruptcy court in which a company’s assets pass to an assignee who liquidates them for creditors. Claims are being administered by Stretto, Inc. at cases.stretto.com/Productiv, with a filing deadline of December 22, 2026. If you think you have a claim, that deadline is the one to calendar. Source: the Stretto case page, which lists the assignor, assignee, effective date, governing law, and claims bar date.

Worth saying plainly: this was a hard week for the people who built Productiv, not just the people who bought it. A team lost their jobs, and a lot of admins lost a tool they genuinely liked and had staked internal credibility on.

If you’re one of those admins, the export advice everyone published in the first week — including ours — is now useless to you. So here is the version that still works: what’s actually gone, what you can rebuild, and how to get most of it back in 30 days.

What you lost versus what you can rebuild

Be precise about this before you promise anything to your VP, because the two halves have very different timelines.

Gone for good. Historical engagement and utilization trends — the multi-year record of who logged into what, how often, and how that curve moved. In-platform notes, tags, saved views, and workflow configuration. Your license-optimization baselines: the “we reclaimed 340 seats last year” numbers that justified the tool. Any benchmark data that was Productiv’s own, not yours. None of this exists anywhere. There is no backup, no escrow, no partner copy.

Recoverable. Your application inventory. Your annual and monthly software spend. Contract terms, renewal dates, and notice periods. App owners and business sponsors. Purchased license counts. Vendor contacts. All of it lives in systems you still control — your identity provider, your finance stack, your contract repository, your endpoints. Productiv aggregated that data; it did not originate it.

That distinction matters commercially, too. If a vendor offers to “restore” or “recover” your Productiv usage history, they are selling you something that cannot be delivered. The honest offer is help reconstructing the recoverable half faster, and starting a new engagement baseline today.

The four sources that get you to ~90% coverage

This is the core of the work. Four pulls, done in parallel by whoever owns each system, will reconstruct most of a mid-market or enterprise SaaS estate. Assign owners before you start — this stalls when one person tries to do all four.

1. Your identity provider. Okta’s System Log, Entra ID sign-in logs, or the Google Workspace audit log will give you every app users authenticated into, with unique user counts and last-sign-in dates. In Okta, export the app list with assignment counts and pair it with 90 days of sign-in events; in Entra, pull the enterprise applications list plus sign-in logs. This is your fastest path to the sanctioned app list and often takes an afternoon. What it misses: anything not behind SSO. Departmental tools bought on a card, free tiers, tools with local logins, and most of the AI apps that arrived in the last 18 months. Shadow IT is defined by its absence from this list.
2. Your finance systems. Pull 24 months of vendor-level spend from the AP ledger (NetSuite, Coupa, or your ERP) plus corporate card and expense feeds (Ramp, Brex, Expensify). Filter on software and subscription GL codes, but also scan uncoded vendors — that’s where the surprises are. This is your only real source for spend, and your best source for apps IT never knew existed. The obstacle is vendor naming: card descriptors like ADOBE *ACROPRO, resellers and marketplaces (AWS Marketplace, SHI, Insight) that mask the actual product, and parent-brand line items that cover several apps at once. Budget real time for normalization; it’s the least glamorous and most valuable hour of this project.
3. Contracts and email. Your contract repository, DocuSign’s completed-envelope list, and the procurement and AP inboxes together reconstruct renewal dates, term lengths, auto-renewal notice windows, and purchased seat counts. Search the shared drive and inboxes for “order form,” “auto-renew,” “renewal notice,” and “MSA.” What it misses: month-to-month and click-through agreements, which usually have no paper at all and show up only in the finance pull.
4. Endpoint and browser signals. OAuth grants (Google Workspace third-party apps, Entra enterprise app consents), browser extension inventories from your MDM, and installed-application reports from Intune, Jamf, or Kandji. This is the layer that catches free and freemium tools — the AI assistants, the note-takers, the design tools — that never touch finance or SSO. It’s noisy and needs filtering, but it’s the only source that sees them.

Then de-duplicate, and expect it to take longer than you think. The same app will appear in three sources under three names. Normalize on the vendor’s root domain rather than the display name, decide up front whether a suite counts as one app or several, and keep a single alias column so Atlassian, Jira, and JIRA SOFTWARE-ANNUAL collapse to one row. Do this once, deliberately, or you’ll ship an inventory with a 15% inflation rate and lose the room’s trust on the first review.

This four-source pull is what automated discovery does continuously rather than once.

Triage renewals before you finish the inventory

Do not wait for a complete estate map. A renewal inside the next 90 days is money leaving the building while you build a spreadsheet.

As soon as the finance and contract pulls are underway, build a single triage list sorted by next renewal date, with known or estimated annual value in the second column. Work only the next 90 days. For each line, do three things:

Confirm the owner. Not the person who signed it two years ago — the person who will defend the spend this quarter. Unowned renewals auto-renew by default, every time.

Find the notice deadline, not the renewal date. Most enterprise agreements auto-renew unless you give 30, 60, or 90 days’ written notice. The notice date is your real deadline, and for anything renewing in the next 60 days it may already have passed. Check this first; it changes what’s negotiable.

Make the call: renew, renegotiate, or kill. You’ve lost your utilization data, so you can’t argue seat reduction from a Productiv report anymore. You can still argue from purchased-seat counts versus IdP-assigned users, from headcount changes since the last renewal, and from department owners telling you plainly whether their team uses the thing. That’s weaker evidence than you had two weeks ago, and it’s enough to hold a renegotiation.

Two practical notes. Ask each vendor for their own usage numbers — most account teams will share seat activity on request, and for your largest apps that partially backfills what you lost. And if a renewal is genuinely un-triageable in time, a short-term extension at the current rate is almost always available and beats renewing blind for another year.

This list is also the artifact Finance actually wants. Send it to them at the end of week one, unfinished, with the coverage gaps labeled.

Rebuilding an engagement baseline

Your usage history is gone, which means the new clock starts today. Every day you delay instrumentation is a day missing from the dataset you’ll need at the next renewal cycle.

Set this up in week one, not week four. Confirm your IdP is retaining sign-in logs long enough to be useful and export them somewhere durable — default retention in most tenants is far shorter than a renewal cycle, and you will not get those days back. Connect directly to your ten largest apps by spend via API for last-active dates, license tiers, and seat assignments; those ten usually carry most of the negotiating leverage. Turn on SCIM where you can, so provisioning and deprovisioning generate a record instead of a ticket. Keep the endpoint and OAuth telemetry flowing rather than treating it as a one-time pull.

Do that and you’ll have 90 days of real utilization data by mid-November, and a full renewal cycle’s worth by next summer.

This is also the argument against solving the problem with a spreadsheet. A hand-built inventory is accurate on the day you finish it and starts decaying immediately — new tools appear, seats change, someone renews without telling you. Worse, a static inventory can’t produce a utilization trend at all, because trends require continuous collection. The rebuild is a one-time project. The baseline is only worth having if something keeps collecting after the project ends.

Doing this in Torii

Everything above can be done by hand. If you would rather not, here is what the same rebuild looks like in Torii, kept short because the method is the same.

Two connections start it. Connect your identity provider and your finance system. Discovery runs immediately against both, and the contract and endpoint sources layer in as you connect them. You are building workflows the same day instead of maintaining the spreadsheet you built last week.

Renewals come back first. Torii rebuilds the renewal calendar before the inventory is complete: current owner, the notice deadline rather than just the renewal date, and a renew, renegotiate, or short-extension decision for each line. That is the 90-day triage list from the section above, generated rather than typed.

What comes back. App inventory from the identity provider, software spend from AP and cards, contracts and renewal dates, app owners and sponsors, purchased license counts, and shadow SaaS and AI tools from browser and endpoint signals. What does not come back is the same for everyone: Productiv’s historical utilization trends, in-platform notes, saved views, and workflow configuration were destroyed, and no vendor can restore them.

Who does the work. You make the two connections. A Torii specialist validates discovery and builds your workflows alongside you. There are no agents to deploy, no services engagement, and no implementation fee.

If we ever part ways. You can export your inventory, spend, contract, owner, and license data by API or CSV at any time, on your own schedule. That is the data egress test from the next section, and you should run it while you are a happy customer.

Torii was named a Leader in the 2026 Gartner® Magic Quadrant™ for SaaS Management Platforms. The Productiv replacement page maps each Productiv capability to what Torii does.

What this changed about vendor selection

The obvious lesson is “pick a bigger vendor,” and it’s the wrong one. Company size is a weak predictor, and anyone using this moment to sell you their headcount is selling you a feeling.

The real lesson is narrower and more useful: ask about data egress before you sign, and test it while you’re a happy customer. Three questions belong in every SaaS evaluation from now on:

• Is there a documented, self-serve export of all my objects — inventory, spend, contracts, usage history — not a CSV of the current view?
• Is continued data availability for some defined window after termination a contractual commitment, or a support-ticket favor?
• Can I pull all of it via API on a schedule I control?

Then actually run that export quarterly and put the file somewhere you own. That habit, not vendor selection, is what would have made last week survivable.

We’ll publish the full vendor continuity questionnaire as a follow-up. In the meantime, the thing worth internalizing is that any promise of permanence — including ours — is worth exactly as much as your ability to walk away with your data.

Still comparing platforms? Our Productiv alternatives roundup covers the field, and the Productiv replacement page maps each capability to Torii.

Most of the new customers we onboard are coming off a spreadsheet.

To be fair, this isn’t new, it’s the normal. But it still struck me as important.

This came up on a recent call at Torii: a batch of new customers had just signed, and someone noticed that most of them were coming from a SaaS management process that relied entirely on one person updating a spreadsheet.

Is this a critical mass moment?

We’ve seen some recent consolidation in the SMP market with vendors like Productiv shutting down. And yet, the SMP landscape is only growing.

In 2025, Gartner claimed that “Through 2028, over 70% of organizations will centralize SaaS application management using a SaaS management platform (SMP), an increase from less than 30% in 2025.”

Adoption of SMPs is growing, and in 2026, it’s actually accelerating as more and more companies struggle to manage AI alongside SaaS.

So why has it taken so long?

Nobody owns the problem.

If most teams have not bought a tool for this, the question worth asking is why not. It is not that the tools are bad or that nobody cares. It is that the SaaS stack belongs to no single person.

Think about who touches it. IT, finance, security, procurement, and department heads each hold a piece of it. multiple owners, multiple priorities, and no one whose job title says “the software estate is mine.” A problem nobody clearly owns is a purchase nobody is clearly assigned to make.

Everything else about the slow adoption hangs off that. The spreadsheet is free, it is already open, and it mostly works right up until the renewal nobody caught. That renewal will not send a calendar invite, and the sheet is not going to volunteer that a seat quietly renewed for another year. When our offboarding conversations turn to the manual state, the way people put it is plain: “the list is only as good as the last time someone updated it”. That is not a complaint about a tool. It is the honest ceiling of a shared sheet that four teams half-maintain.

“SaaS management” is also young enough that most teams do not yet expect it as a budget line or a slot on the org chart.

So no, you’re not late to SaaS management… yet

If you’re still updating that spreadsheet by hand; bless you.

You’re keeping things on track, trying to monitor adoption, track spend, inventory the un-inventoriable, and anticipate the new surprise renewal. It’s not just hard work, it’s impossible in the modern workplace.

We say it all the time, but SaaS Management requires cross team collaboration. Not a single hero, but a structured effort that comes from the top. Now, in a world of shadow IT and rampant AI adoption, that effort of managing your software is more important than ever.

On August 2, 2026, Productiv announced it was sunsetting its SaaS management platform on August 6, 2026 — a four-day window between the announcement and the shutdown. In practice the window was shorter: Productiv terminated customer access on August 5, and ceased operations on August 6. The company did not publicly give a reason for the decision.

Productiv itself has never stated a cause, and we are not going to manufacture one. What the public record does show, as of September 2026, is the mechanism: a General Assignment for the Benefit of Creditors effective June 25, 2026, more than five weeks before customers were told. That is covered in the next section. For the teams affected, the timeline still matters most, because four days is not much runway to move a system of record.

So why did Productiv shut down?

Productiv has never given a public reason. When this post was first updated on August 11, the only signal was that its website directed creditor claims to a third-party administrator, which pointed to a wind-down rather than a planned product sunset.

Update, September 9, 2026: the public record now shows the mechanism. Effective June 25, 2026, Productiv, Inc. made a General Assignment for the Benefit of Creditors to PFS Productiv Liquidation LLC, a California limited liability company, under California law. Stretto, Inc. is administering claims, and the deadline to file one is December 22, 2026.

An assignment for the benefit of creditors is a state-law alternative to a Chapter 7 bankruptcy: a company transfers its assets to an assignee, who liquidates them and distributes the proceeds to creditors in order of priority. It is faster and more private than a court filing, which is consistent with how little was said publicly. It does not tell you why the business failed, and Productiv still has not. But it does establish that the wind-down was set in motion at least five weeks before customers were told on August 2.

Source: PFS Productiv Liquidation LLC case page, Stretto, Inc., which lists the assignor, assignee, effective date, governing law, and claims bar date.

If you believe you have a claim as a former customer, the December 22 deadline is the one to calendar. Our rebuild guide covers what former customers can and cannot recover.

What Productiv was

Productiv was a SaaS management platform best known for leaning on engagement data — measuring not just which applications a company bought, but how often employees actually used them. That angle made it popular with large enterprises trying to prove license utilization and justify renewals. For those customers, Productiv often held the authoritative view of the app portfolio: the inventory, the usage signals, the spend, and the app owners.

When a platform like that goes away, the risk is not just losing a dashboard. It is losing the visibility that IT, Finance, and Procurement teams had come to rely on for renewals, license decisions, and offboarding.

What the shutdown means for customers

With the sunset set for August 6, current Productiv customers face an immediate, practical problem rather than a long-term evaluation.

Your Productiv data is gone — here’s what that actually means

There is no export window left, and no recovery path. Productiv states that all production systems, data stores, and backups have been permanently destroyed, with no customer data retained. Any vendor telling you to “export before it’s too late” is working from a week-old script.

What that means in practice:

• Permanently lost: historical engagement and utilization trends, license-optimization baselines built on that history, and any workflow configuration or notes held inside the platform.
• Fully recoverable: your app inventory, software spend, contract and renewal dates, app owners, and license counts. All of it can be reconstructed from systems you still control — your identity provider, your AP and expense data, your contract repository, and endpoint or browser signals. It takes days, not months.

The immediate priority is any renewal inside the next 90 days, because that’s where an invisible auto-renewal turns into real money. Everything else can be rebuilt on a slower clock.

We wrote up the full method, source by source, in how to rebuild your SaaS estate from zero after Productiv, including the renewal triage.

Beyond the data itself, two priorities remain:

• Re-establish discovery fast. The longer you go without a system tracking your SaaS estate, the more visibility and savings leak away in the gap — missed renewals, idle licenses, and shadow IT that no one is watching.
• Choose a replacement that can ramp quickly. A discovery-first platform can rebuild much of what you lose automatically, through integrations, rather than forcing you to start from a blank spreadsheet.

What to do next

Because there is nothing left to export, the platform you choose has to rebuild your SaaS estate on its own — not inherit it from Productiv. That is exactly what a discovery-first platform does: it reconstructs your app inventory, spend, owners, and licenses from the systems you still control, instead of depending on a previous vendor’s records. We put together a side-by-side look at the strongest options — Torii, Zylo, Zluri, 1Password (Trelica), and Flexera — in our guide to the top 5 Productiv alternatives for SaaS management.

Among them, Torii is the closest direct replacement: a discovery-first platform, named a Leader in the 2026 Gartner® Magic Quadrant™ for SaaS Management Platforms, that rediscovers your estate automatically and ties every app, license, and AI tool back to a real owner and budget — then automates the renewals, license reclamation, access reviews, and offboarding that Productiv largely left to manual effort. With customer access already gone, that combination of from-scratch discovery and automation is the fastest way back to control.

Which apps are underused?
Which contracts are coming up for renewal?
Who owns this app?
Did this offboarding workflow finish?
What changed in our SaaS stack last week?

That work takes time because the context lives in different places.

Torii’s hosted Model Context Protocol (MCP) server gives AI assistants a secure way to access your Torii data directly. Connect tools like Claude, ChatGPT, Cursor, and other MCP-compatible clients to Torii, and your assistant can query apps, users, contracts, workflows, audit logs, transactions, and more.

The best part: Torii MCP uses your existing Torii account permissions. Your assistant can only access the data and actions available to you.

How it Works

MCP is an open standard that lets AI tools connect to external systems through a shared interface. Instead of building one-off integrations for every AI tool, MCP gives compatible assistants a common way to talk to systems like Torii.

For Torii users, that means SaaS insights that once required the UI, manual reporting, or custom API work can now be surfaced directly in the AI tools your team already uses.

With Torii MCP, your assistant can help you access information like:

• User details
• Contract details
• Audit log history
• Application details
• Workflow activity
• Transactions
• SaaS costs
• Renewal data
• App ownership
• And more

Depending on your permissions, your assistant may also be able to take supported actions in Torii, such as searching apps, matching app records, creating contracts, updating users, or running workflows.

Hosted MCP, No Local Setup Required

Torii’s MCP server is now hosted, so you can connect your AI assistant directly to Torii without installing packages, running a local server, or managing API keys.

Connect your MCP-compatible client to Torii’s hosted MCP server:

https://api.toriihq.com/mcp

From there, sign in with your Torii account and approve the connection. Torii uses OAuth and your existing Torii role permissions, so your assistant only gets the access you already have inside Torii.

Torii’s hosted MCP server can work with AI clients that support remote MCP servers with OAuth, including tools like Claude, ChatGPT, Claude Code, Cursor, Windsurf, Zed, Cline, Continue, and custom apps built with official MCP SDKs.

Torii MCP in Action

Below, see how a few prompts reveal offboarding status, ownership gaps, and replacement recommendations in seconds.

With just a few prompts in Claude, the user learns that:

• Six employees are currently in an offboarding workflow, and only one — Melba Donnelly — has not been deleted yet.
• Melba is still the app owner for Box.
• Claude can pull a list of active Box users, analyze usage, and suggest four candidates to take over ownership.

That is a simple example, but it shows the larger value: IT teams can move from question to answer without manually checking multiple screens, exporting data, or building a report first.

What You Can Ask

Once connected, your AI assistant can help answer questions like:

• Which apps have more than 100 users?
• Which contracts are renewing in the next 60 days?
• Which apps have the most unused licenses?
• Who owns this app?
• Which users have access to this app?
• What workflows ran in the last seven days?
• Which apps were added last month?
• What changed in our SaaS stack this week?

You can also use Torii MCP to dig deeper. For example, you might ask your assistant to find apps with high spend and low usage, identify contracts that need attention, or review recent workflow activity before a meeting.

Why It Matters

AI is only useful when it has the right context.

For SaaS management, that context lives in Torii: your apps, users, contracts, costs, workflows, ownership data, and audit history. Torii MCP brings that context into the AI tools your team already uses, so you can ask better questions and get faster answers.

That helps IT, procurement, finance, security, and operations teams:

• Reduce manual reporting
• Find SaaS risks faster
• Spot cost-saving opportunities
• Understand ownership and access
• Review workflow activity
• Prepare for renewals
• Make decisions with fresher data

Instead of asking your team to jump between systems, Torii MCP lets them start with a question and move straight toward the answer.

How to Get Started

Ready to connect your AI assistant to Torii?

Use Torii’s hosted MCP server:

https://api.toriihq.com/mcp

For step-by-step setup instructions, see the support guide: Connecting AI Assistants to Torii with MCP.

Want to learn more about the standard behind it? Read the Model Context Protocol specifications.

Torii MCP helps your team bring live SaaS context into the AI tools they already use, so they can move faster, reduce manual work, and manage software with more confidence.

Prefer a Local MCP Setup?

Torii’s hosted MCP server is the recommended setup for most users because it does not require local installation, API key management, or running your own server.

For teams that prefer a local setup, Torii also offers a local MCP server package that can run on your machine and connect to Torii through your API key.

Install the package:

npm install @toriihq/torii-mcp

You’ll need:

• A Torii API key
• Node.js
• Yarn package manager

A local setup may be useful if your team wants more control over how the MCP server runs, needs to test MCP behavior in a development environment, or is connecting through a client that does not support hosted remote MCP servers yet.

For most users, we recommend starting with the hosted MCP server:

https://api.toriihq.com/mcp

For local setup instructions, visit Torii’s npm repository or contact your Torii Customer Support Representative.

In January 2023, Grammarly appeared in just 17% of customer environments. By January 2026, it had jumped to 47%. The growth wasn't steady — it came in three distinct waves, each driven by something specific Grammarly did.

Here's what the data looks like, and what was happening at Grammarly each time the line jumped.

Spike 1 (Feb–Mar 2024): Grammarly stopped being a spell-checker

On March 26, 2024, Grammarly launched Strategic Suggestions — AI-powered recommendations that went beyond fixing grammar to advising on audience, tone, and persuasion. The same week, it shipped App Actions, letting users trigger tasks in tools like Asana and Google Calendar from within Grammarly. For the first time, the product could make a real case to IT and procurement as a productivity platform, not a writing add-on.

Fast Company added fuel. Its 2024 Most Innovative Companies list (published March 19) named Grammarly in the AI category and cited some striking ROI numbers: one healthcare customer reported 28x ROI, and Grammarly claimed average savings of $5,000 per employee per year. That kind of coverage circulates in the procurement channels where enterprise software decisions get made.

Spike 2 (Dec 2024–Jan 2025): A new CEO, a new company

On December 17, 2024, Grammarly announced it was acquiring Coda — a collaborative workspace product competing with Notion and Google Docs — and that Coda's co-founder Shishir Mehrotra would become Grammarly's new CEO. The message was explicit: Grammarly was no longer a writing tool; it was building an AI productivity suite for enterprise teams.

That announcement closed a pipeline that had been building since October. Two months earlier, Grammarly had landed on the AWS Marketplace, giving companies with existing AWS commitments a way to apply cloud credits toward Grammarly Business — a procurement shortcut that removes significant friction. In the same October window, Grammarly launched Billing Groups, ServiceNow integration, and group-level security controls: the exact features IT admins need before they can deploy something organization-wide.

The jump from 30% in December to 38% in January reflects deals that probably started in Q4, enabled by the AWS listing and admin tooling, then accelerated by the Coda news.

Spike 3 (Sep–Oct 2025): The Superhuman rebrand

On July 1, 2025, Grammarly acquired Superhuman — the AI email client valued at roughly $825 million. Three months later, on October 29, Grammarly rebranded the entire company as "Superhuman" and launched the Superhuman Suite: four unified products (Grammarly writing, Coda workspace, Superhuman email, and a new AI agent platform called Superhuman Go). The rebrand landed across TechCrunch, Fast Company, Built In, and others simultaneously.

Usage in our dataset went from 35% in August to 41% in September and 46% in October. September also brought a Forbes Cloud 100 placement at #11 — the kind of analyst recognition that validates a platform to IT procurement teams evaluating AI investments. A $1 billion non-dilutive funding round announced in May, earmarked for sales and marketing scale, almost certainly put more reps in front of enterprise buyers during this window.

What this means for IT teams managing SaaS

Each of these spikes followed the same pattern: Grammarly expanded what the product does, and enterprise adoption followed. That creates a specific challenge for IT.

In 2023, most companies probably had Grammarly as an employee-purchased tool — a $12/month browser extension people expensed without telling IT. By 2026, the product has become a full AI productivity suite with admin controls, data governance features, and enterprise licensing that IT should be part of evaluating and managing.

If you're not tracking which tools are gaining momentum in your organization, you'll find out about the enterprise version of Grammarly (or Superhuman, now) after someone in marketing has already signed a contract. The best position is to see the adoption curve before the renewal conversation happens.

Torii surfaces that kind of usage data automatically — which apps employees are using, which ones are growing, and which ones have grown to the point where IT needs a seat at the table. Book a demo to see how it works.

Related reading:

• How to Detect OAuth Risks in Google Workspace and Who\u2019s Behind Them in 2026
• What is a Log Analysis?
• 7 Ways to Reduce Your SaaS Costs Without Losing Productivity

The Torii CLI is an OpenAPI-driven command line interface that lets you explore the Torii API, inspect schemas, and run API calls directly from your terminal. Every command is auto-generated from the live OpenAPI spec, so it stays in sync with the latest API capabilities without manual updates.

If you're writing automation scripts, building data pipelines, or connecting Torii to AI agents, this is your starting point.

Why a CLI?

Point-and-click interfaces work for exploring. But when you need to pull license data into a report, trigger a workflow from a script, or pipe SaaS usage stats into another tool, a CLI is faster and more composable. Every response comes back as structured JSON, so it works out of the box with jq, shell scripts, and automation frameworks.

The Torii CLI is built for:

• Automation scripts — schedule recurring data pulls or trigger actions on a cron
• Data extraction pipelines — export application, user, and contract data for analysis
• AI and agent integrations — feed Torii data into LLMs, Claude Code, or custom agents
• Interactive exploration — browse available endpoints and test calls before writing code

Getting Started

Install globally via npm, or run it directly with npx if you just want to try it out.

# Install globally
npm install -g torii-cli

# Or run without installing
npx torii-cli discovery

Before running commands, set your API key as an environment variable:

export TORII_API_KEY="your-api-key"

That's it. You're ready to query your Torii instance from the command line.

How It Works

The CLI dynamically fetches the OpenAPI specification from the Torii API. This means you don't need to memorize endpoints or check documentation every time the API changes. Run the discovery command to see every available operation:

# List all available API operations
torii-cli discovery

This returns a JSON list of every endpoint, generated directly from the spec. From there, you can run any operation. For example, to pull your top 10 applications:

# List your first 10 applications
torii-cli apps list --size 10

All responses are structured JSON, which makes it easy to pipe into other tools or parse in scripts.

Pairing Torii CLI with AI Agents

One of the most practical uses for the Torii CLI is connecting your SaaS data to AI-powered tools. Because the CLI returns structured JSON and supports the same operations as the API, it works well as a data source for LLMs and coding agents.

Here's what that looks like in practice. Below, a user asks Claude Code how many people in their company are using ChatGPT, Gemini, and Claude. Claude queries the Torii API to pull real usage data and return an answer in seconds.

Instead of logging into a dashboard, filtering by app category, and exporting a spreadsheet, the user gets an answer through a natural language prompt. The CLI (and the broader Torii API) makes this kind of integration straightforward.

This pattern applies to more than just usage questions. You can build agents that flag expiring contracts, identify orphaned accounts, surface license optimization opportunities, or generate compliance reports, all powered by the same API the CLI uses.

What You Can Do With It

The CLI gives you access to the same data and actions available through the Torii platform. A few examples:

• Pull application inventory — list all discovered apps, filter by category, and export for audits
• Query user data — check who has access to what, identify inactive accounts, and track usage
• Monitor contracts and spend — surface renewal dates, license counts, and cost data
• Feed data into CI/CD or reporting tools — pipe JSON output into dashboards, Slack alerts, or ticketing systems
• Build custom automations — combine CLI calls with cron jobs, shell scripts, or orchestration tools

Get Started

The Torii CLI is available now on npm. Install it, set your API key, and start querying your SaaS data from the terminal.

For full documentation, visit the Torii Developer Docs.

Already a Torii customer? Reach out to your Customer Success representative to get your API key and start building.

Book a demo to see how Torii helps teams manage SaaS with automation, visibility, and developer-friendly tools.

Then you have shadow AI usage and tool overlap, leading to cost optimization questions like, "We use Google Workspace, which has Gemini built in. Why also pay for ChatGPT?" or "Why are we paying so much for Cursor when we could just use Claude Code instead?"

The good news: it's possible to track AI costs in 2026 down to the cent, as well as easily identify overlapping AI tools. This guide breaks down how to track AI costs in 2026: what to measure, how to do it manually, and how platforms like Torii give you a real-time view across your entire AI stack.

Why is AI Spending Harder to Control Than SaaS?

Traditional SaaS follows a predictable model: pay $X per month, or per seat per month. In either model, predicting costs is easy (it'll be the same cost unless you add more people). AI tools have upended this with their focus on 'token-based' pricing and generally opaque insights into usage.

Usage-based pricing is of course not new. Tools like Stripe (commission %), Twilio (PAYG usage), and Hubspot (cost per marketing contact) have used them for years. Not to mention Google Cloud and AWS's cloud compute costs. But these are much more predictable than AI token pricing, and the norm for SaaS is still monthly/yearly pre-set commitments.

Meanwhile, AI tool usage is...confusing? Odd? Misleading? Just take a look at this API pricing breakdown from OpenAI.

Understanding costs here is a nightmare. What model are you using? Are we caching or not? Is this batch, flex, or standard? How do I track how many tokens any given message contains? At least with standard request-based PAYG pricing you know that 1 request = 1 request to pay for.

On top of that, you have shadow AI. Employees are signing up for their favorite new AI tools, even though they may overlap significantly with tools your company already pays for. Then, of course, people may be signing up for ChatGPT themselves when a team plan would be much more economical.

The costs can compound quickly. A 100-person engineering team could be running Cursor, GitHub Copilot, and Claude Code simultaneously, each doing roughly the same thing. At standard pricing, that's anywhere from $70,000 to $130,000 per year in coding AI alone.

This differs from traditional SaaS because normally it's easy to identify overlaps. If you're working with Box.com, it may feel weird to also work in Dropbox for some projects, since they are effectively the same tool. Gemini and MidJourney, on the other hand, may not feel that way. Yet, with the speed of AI innovation, the difference between AI tools is shrinking. Maybe you paid for Gemini Nano Banana because it was the best image generator, then switched to MidJourney the next month because it seemed better, and so on - until you just decide to keep paying for both. (Or, you were using MidJourney not knowing Gemini was also a great image generator).

How Do I Track AI Costs Manually?

The manual approach to AI cost tracking is where most companies begin. For small companies, it's relatively simple: you log into each tool's billing dashboard separately (the OpenAI usage page, the Copilot admin console, Cursor Teams billing), pull the numbers, and paste them into a spreadsheet. Then you cross-reference expense reports to catch anything employees bought on their own.

This approach works passably when you have two or three tools and one person keeping the spreadsheet current. It doesn't hold up as your AI stack grows.

The core limitation with manual tracking comes down to visibility lag between spending and awareness. Each billing dashboard gives you a static snapshot from a single vendor. You have no cross-tool view of what an individual employee is spending across their whole AI stack. You can't see that one developer has active subscriptions to Cursor, Claude Pro, and ChatGPT running at the same time.

A second blind spot with manual tracking is that it tells you nothing about license utilization. A billing dashboard shows what you're paying, not what's being used. You can have 50 Copilot seats and only 20 active users, and the invoice looks the same regardless. Finding that waste requires comparing the bill against actual login data, which most AI tool billing dashboards don't surface.

How Can I Track Costs with Torii?

Torii is an AI Management Platform that replaces the per-tool billing dashboard approach with a single consolidated view. Torii's AI Apps Spend dashboard pulls all your AI tool costs into one place: total spend by tool, last 30 days vs. last 12 months, user counts, and license utilization.

That last column is where the real value shows up. If Lovable is sitting at 38% license utilization, that means 62% of the seats you're paying for aren't actively used. That's not easily visible within Lovable alone. In Torii, it surfaces right next to the cost number so you can act on it immediately.

Additionally, the spend-over-time chart surfaces growth trends that a manual spreadsheet would never flag in time. Cursor spend jumping from roughly $1,400 per month to over $5,400 in two months is a signal worth investigating: is the team growing, or are a handful of power users burning through credits on a premium model? Seeing the trend is the first step to asking the right question.

How Do I Cut My AI Costs?

Seeing your AI spend is the starting point, not the finish line. Once you have a consolidated view, four actions consistently move the number down.

Reclaim idle seats. For AI tools with seat-based pricing, any AI license that hasn't been accessed in 90 days is waste. License reclamation at this threshold can cut AI tool costs by 20-35% in organizations that haven't been actively managing it. Set a policy, automate the reclaim, and redirect those seat costs elsewhere.

Identify tool overlap. Once you can see every AI tool in use, consolidation decisions become obvious. If multiple teams are each paying for a coding assistant, pick one standard. If you have three separate LLM subscriptions doing similar work, consolidate. A tool like Torii can help surface those duplicate tools easily.

Rightsize tiers. Actual usage data removes the guesswork from tier and contract decisions. If 60% of your Copilot users are only accessing basic features, downgrade those seats. Annual contracts save 10-20% over monthly billing for tools you're committed to keeping long-term.

Set ongoing guardrails. Treat AI spend like cloud compute: allocated per team, monitored monthly, with budget alerts at 80% of the limit. Require new AI tool requests to pass a lightweight approval that checks for overlap with existing tools. The goal isn't to slow down adoption. It's to stop paying for the same capability twice.

Monitor outliers. If a certain tool or user is causing costs to climb, why is that? Perhaps there is wayward automation running, or an expensive model is being used when a more cost-efficient one would suffice. Review and set guidelines on model and token usage.

AI tool adoption isn't slowing down, and neither is the spending that comes with it. Enterprise AI-native app spend grew 108% year-over-year in 2025, and with more tools hitting the market every month, the overlap problem will only compound. The companies that stay ahead of it are the ones that treat AI spend the same way they treat cloud compute: tracked by team, reviewed regularly, and tied to actual outcomes.

The path forward isn't complicated. Know what you have, know what's being used, and build a repeatable process to act on that data. Whether you start with a manual audit or a platform like Torii that consolidates everything into one view, the goal is the same: visibility that lets you make decisions before you get surprised by a five-figure invoice.

See how Torii tracks your AI spend across every tool. Book a demo.

Related reading:

• What Is a Toxic Combination in SaaS in 2026?

Executive Summary

Identity Governance & Administration (IGA) is no longer a back-office task. It is a board-level responsibility. Identity is now central to enterprise risk, regulatory compliance, and shareholder value.

The pressure is mounting from every direction:

• Breach reality: Ransomware features in 44% of breaches, the human element is present in nearly 60%, and third-party exposure has doubled to 30%.
• Financial impact: The average breach costs $4.4M, while most organizations hit by AI-related incidents lacked basic access controls.
• Regulatory heat: Boards face direct accountability under DORA (resilience and third-party oversight), NIS2 (expanded obligations with active enforcement), and the SEC cyber rule (4-day disclosure of material incidents).
• Business reality: Enterprises now run an average of 1,850 SaaS apps. Machine identities outnumber humans 82:1, and AI systems are emerging as new “users” with access needs of their own.

The good news is that IGA delivers results quickly. 

This blueprint gives boards, executives, and audit committees the tools to turn identity governance into a measurable, board-sanctioned program. Specifically, it will:

• Outline clear accountability: Show exactly who should own which responsibilities—from board and committee oversight, to executive sponsorship, to daily operations through an IGA council.
• Provide a reference architecture: A vendor-agnostic model of the essential layers of IGA (sources, control plane, Zero Trust, PAM, ITDR, AI guardrails, reporting) that boards can use to judge maturity.
• Define a board-ready KPI framework: A concise set of metrics and targets mapped directly to regulatory requirements, so progress can be tracked quarter by quarter.
• Map controls to standards: Demonstrate how IGA outcomes align with NIST CSF 2.0, DORA, NIS2, and SEC rules—simplifying reporting and audit prep.
• Deliver a 180-day SaaS sprawl plan: A phased approach to bring shadow IT, vendors, and machine identities under governance, with quick wins in the first 30 days.
• Show the ROI case: Translate governance outcomes into financial language—license reclamation, audit efficiency, and avoided breach losses—so CFOs and boards can clearly see value.

The takeaway is simple: IGA is the control plane for digital risk. It enables boards to prove compliance, reduce exposure, and demonstrate financial value—turning identity from a hidden liability into a governed asset.

IGA is a Board-Level Concern

For years, identity was treated as a back-office function. It was something that IT, SecOps, and vendor management dealt with. But today, that era is over.

Identity is a board-level concern because it directly impacts enterprise risk, regulatory compliance, and shareholder value. 

The facts are clear: stolen or misused credentials are still the easiest way for attackers to get in to the organization. 

According to  Verizon’s DBIR 2025 reports:

• Ransomware was involved in 44% of breaches
• The human element was present in ~60%
• Third-party involvement doubled year over year to 30%

 IBM’s 2025 study pins the average cost of a breach at $4.4M.

Additionally, they highlight a massive AI oversight gap. Among the orgs reporting an AI-realted security incident, 97% lacked proper AI access controls.

As financial impacts grow, regulatory leashes tighten.

In Europe, DORA now requires boards of financial institutions to prove resilience across their ICT and vendor ecosystems. NIS2 is expanding the obligations across industries, and the commission is already escalating against 23 lagging states. In the US, the SEC cyber  disclosure rule now forces boards to disclose material incidents within four business days.

Each of these rgulations asks the same question of the board: Can you prove, right now, that you know who (or what) has access to what?

Along with the financial and  regulatory risk, there is the business reality. 

Organizations use:

• More applications than ever, with enterprises often leveraging over 1,800 apps
• Machine identities, outnumbering human identities 82 to 1 
• More AI solutions than ever before

The takeaway is simple: IGA is the control system for digital risk, the foundation of zero trust, and the evidence trail that boards need for regulators and investors. Without it, companies risk breaches, regulatory fines, missed disclosures, and loss of market trust. However, there is also an opportunity. With an IGA architecture in place, boards gain measurable resilience, faster audits, and the ability to show ROI in just a few quarters.

In this piece, we’ll build out a reference architecture for your IGA Blueprint. This guide is vendor agnostic, instead it outlines the key building blocks and the relationships between them.

Reference Architecture: The Core Layers of IGA 

If IGA is indeed a board-level concern, the next logical step is to show the board what a good outcome looks like. That is the purpose of a reference architecture, it is a blueprint of the essential layers that every enterprise needs in place to govern identity effectively.

These layers are non-negotiable building blocks of modern identity governance. Different organizations might use different language to describe some of the business functions included, but the processes and outcomes should be similar. Each layer addresses real-world weaknesses that attackers exp[loit and regulators scrutinize. Together, they form the control plane that allows boards and executives to both reduce risk and prove compliance.

The Core Layers of IGA

• Identity Sources & Context: The “source of truth” for who people are, who vendors are, and what machines or AI agents exist. Without authoritative sources, everything else falls apart.
  
• IGA as the Control Plane: Where governance actually happens: automating joiner/mover/leaver processes, approving or denying access requests, enforcing segregation-of-duties rules, and running certifications. This is the heartbeat of the architecture.
  
• Zero Trust Enforcement: Access is never granted by default. Instead, users must prove themselves continuously via SSO, MFA, device posture, and least-privilege rules, every time they connect.
  
• ITDR (Identity Threat Detection & Response): Because policies aren’t enough, ITDR provides the ability to detect stolen tokens, anomalous logins, or suspicious privilege escalation and shut it down fast.
  
• Privileged Access Management (PAM): Admin accounts are the master keys to the kingdom. PAM ensures they’re controlled, time-boxed, monitored, and rotated whether human or machine.
  
• Third-Party & Supplier Access: Many of today’s breaches start with a vendor. Extending IGA controls to suppliers ensures that partners play by the same rules and that offboarding happens the moment a contract ends.
  
• AI Identity & Data Guardrails: As AI systems become active participants in workflows, they must be governed as identities too. Who can they access? What can they see? How are their API keys rotated?
  
• Evidence & Reporting: You need proof. Audit trails, attestation reports, and clear metrics that map directly to DORA, NIS2, and SEC requirements. This is what lets the board sleep at night.

We’ve laid out the core layers of the reference architecture, these building blocks make up an enterprise-grade identity governance program. But layers on a diagram won’t move the board. Now it’s time to establish KPIs and targets that you can measure against.

Board-Ready KPIs and Targets (90-Day to 3-Quarter Trajectory)

What directors, audit committees, and CFOs need is a scoreboard: a small set of measurable outcomes that prove whether the architecture is working and whether the investment is paying off. 

In this section, we’ll lock down KPIs and targets so you can see and prove your progress.

Think of these as your CEO/CFO-safe metrics. They’re clear, auditable, and can be tied directly to regulatory requirements or financial returns. They also have the advantage of being time-bound: progress can be demonstrated in as little as three quarters. 

We’ll break these KPIs into five groups.

Identity Hygiene & Lifecycle

• Orphaned accounts (both human and non-human): Accounts without owners are a breach waiting to happen.
  • Target: Reduce known orphaned accounts by 80% in 2 quarters.
  • Tip: Reconcile IdP/IGA directories against HRIS and the vendor master/NHI registry. Prioritize by: app criticality, privilege level, data sensitivity, and last login.
• Time-to-deprovision (JML): When someone leaves, or a vendor contract ends, access should disappear immediately.
  • Target: ≤ 4 hours for SaaS; ≤ 24 hours for infrastructure.
  • Tip: Start the clock at the HR “termination effective” timestamp; stop it when tokens/sessions are revoked. Automate HRIS → IGA → SSO/SCIM, add a one-click “kill switch,” and run monthly mystery-user tests.
• % apps under SSO + SCIM-based lifecycle: Coverage is control; if it’s not behind SSO and SCIM, it’s hard to govern.
  • Target: 80% coverage; prioritize the top 50 apps by risk/use.
  • Tip: Build an app register (criticality, user count, SSO/SCIM support, owner). Migrate in waves (top 25, next 25, long tail). Require SSO/SCIM in new-app intake and vendor contracts.
• Service/NHI with owner + rotation policy: Bots and keys are identities too; unowned secrets become permanent backdoors.
  • Target: 95% have an accountable owner; secrets MTTR ≤ 7 days (vs. DBIR’s 94-day median).
  • Tip: Discover NHIs via cloud IAM, CI/CD, and secrets scanners. Require Owner and Purpose fields for any token/key. Enforce TTLs and auto-rotation; break builds on expired/unknown secrets. Weekly reports: “NHIs without owner” and “secrets >7 days after exposure.”

Governance & Assurance

• % access under review: Certifications keep real-world access aligned with policy.
  • Target: ≥ 95% on schedule (quarterly for critical apps; semiannual for the rest).
  • Tip: Scope by risk tier. Show delta-only changes to reviewers. Auto-revoke non-responses after X days with advance reminders; escalate misses to the app owner’s VP.
• SoD violations (opened vs. closed) + age: Toxic combinations enable fraud; the point is how fast you burn down the backlog.
  • Target: ≥ 85% closed within 30 days.
  • Tip: Seed SoD rules from Finance (P2P/O2C/GL) and Cloud Ops (deploy vs. approve). Triage by monetary/material risk and privilege level. Track oldest open and repeat offenders; require compensating controls or removal.
• Exception debt (temporary access): “Temporary” tends to become permanent unless engineered to expire.
  • Target: ≥ 98% auto-expire on time.
  • Tip: Default expiry (e.g., 7 days) for all exceptions; disallow no-end-date grants. Monthly leadership report: exceptions >30 days. Treat break-glass the same, time-boxed, recorded, reviewed.

Risk & Detection

• Privileged accounts with phishing-resistant MFA: Admins hold the master keys; weak MFA isn’t acceptable.
  • Target: 100% coverage.
  • Tip: Inventory privileged roles (cloud/domain admins, root, CI/CD, finance superusers). Enforce WebAuthn/FIDO2 or platform authenticators; block SMS/voice for these roles. Maintain a short, dated exceptions list with remediation owners.
• High-risk identity alerts MTTR (ITDR): Time-to-contain drives breach impact; automation wins.
  • Target: ≤ 1 hour to containment.
  • Tip: Pre-define “high risk” (token theft, impossible travel + privilege, lateral movement to crown-jewel apps). Auto-contain (kill sessions, revoke tokens, force reset). Measure start (alert create) and stop (containment evidence). Run a monthly game day.
• Third-party/vendor identities governed: Vendors are part of your attack surface, and often the easiest path in.
  • Target: ≥ 90% via IGA/SSO/PAM; inactive vendor access = 0.
  • Tip: Integrate vendor master with IGA. Make IdP-only onboarding a contract term. Require named vendor managers who attest access quarterly. Auto-disable on contract end or 30 days of inactivity.

Regulatory Readiness

• DORA/NIS2 control attestations: You can’t comply without evidence; mapping controls avoids audit surprises.
  • Target: Controls mapped and evidenced across third-party risk, incident playbooks, and continuity.
  • Tip: Build a control-mapping matrix: Reg requirement → Control owner → Evidence source → Test cadence. Store proofs in an “evidence locker” with timestamps. Do quarterly mini-audits instead of annual scrambles.
• SEC 8-K readiness (4 business days): If identity failure triggers a material incident, the clock starts immediately.
  • Target: Able to determine materiality and draft disclosure within 4 business days; tabletop tested.
  • Tip: Define a materiality rubric, escalation tree (CISO–GC–CFO–IR), and pre-approved templates. Time the tabletop from detection → decision → draft and stage identity evidence (logs, revokes, certifications).

ROI & Efficiency

• License reclamation via deprovisioning: Every orphaned seat is wasted spend; deprovisioning helps fund IGA.
  • Target: Report gross savings/quarter; make the number visible to Finance.
  • Tip: Focus on the top 10 apps by spend. Link revokes to seat removal (not just disabling). Publish a monthly “savings realized” report and forecast next-quarter savings from today’s pipeline.
• Access request cycle time: Faster access improves productivity, without increasing risk when guardrails are solid.
  • Target: Reduce median hours; show productivity regained.
  • Tip: Offer pre-approved catalog roles for low-risk access with auto-approval. Route only sensitive requests to multi-step approvals. Instrument median by app and owner; spotlight bottlenecks.
• Audit prep time: Continuous evidence shrinks effort and findings.
  • Target: Fewer hours vs. last cycle; fewer exceptions/findings.
  • Tip: Move to continuous evidence collection. Keep “audit-ready packs” per control (policy, config, sample, attestation). Give auditors read-only access to standard exports; track hours saved YoY.

This a comprehensive list of KPIs and Targets moving forward. The best way to operationalize this quickly is to pick the right denominators (i.e. top 50 apps by risk/spend + all privileged/NHI + all vendors), set a weekly burn-down goal for backlog KPIs (i.e. orphaned, SoD, exceptions), and automate timestamps for time-to-deprovision, mean time to respond/recover, and reviews (access certifications). 

A lot of organizations estimate numbers, but they aren’t measuring them. But, regulators and auditors don’t want your gut feel, they want system logs. Ensure that you are always measuring and making progress on those numbers. 

Operating Model & Governance

A blueprint and a set of KPIs is only half the job. The other half is making sure the right people own the right parts of the system. This is where your operating model is critical. 

Think of it as an accountability map:

• Who sets the rules
• Who enforces the rules
• Who provides the oversight

The Board and Committees

The board and its audit/risk committee own the highest level of responsibility. They don’t manage the day-to-day minutia, but they do keep track of progress on a longer time horizon. 

Board and Audit/Risk Committee Responsibilities:

• Set the organization’s risk appetite for identity and access.
• Review KPI dashboards quarterly just as they do for financials
• Oversee compliance with regulatory regimes such as the SEC cyber disclosure, DORA, and NIS2

Their job is to ask tough questions in response to what they see. As KPIs start to roll in and conversations with regulators proceed, the board must keep focus on what matters.

“How many orphaned accounts remain?”

“Are we within SLA for vendor offboarding?”

“Can we prove it if regulators call?”

Often, the most importan thing they can do at this level is say “Prove it to me before I have to prove it to someone else.”

The Executive Triad (CISO, CIO, CFO)

The executive triad consists of the CISO (accountable), CIO (co-owner), and CFO (controls). Together, these three roles create the charter, policy, and funding for identity governance. 

• CISO: Ultimately responsible for IGA control effectiveness and for reporting the results to the board
• CIO: Shares ownership, particularly around integration with infrastructure and the application portfolio
• CFO: Responsible for cost controls, ROI measurement, and financial compliance

The IGA Council

Now we are at the level of daily execution. Your IGA council is a cross-functional team. A group that meets regularly (bi-weekly or monthly) to keep everyone in lockstep throughout the organmization. The IGA council should include representatives from: 

• Security
• IT/Identity Operations
• HR
• Procurement
• Legal
• Application Owners

The council is responsible for the practical elements like the Segregation of Duties catalog, the Joiner/Mover/Leaver SLAs, and Vendor Access Policies. Their work ensures that there is allingment across functions so no single team carries the full burder or stalls the entire initiative. 

In Summary: 

• Board: Approves the risk appetite and receives regular attestations.
• CISO: Accountable for IGA controls being effective and reported.
• IT Ops/Identity Team: Responsible for lifecycle automation, connectors, SCIM integration, and operational execution.
• App Owners: Approve or deny access, maintain SoD policies, and attest to who should have access.
• Procurement/Vendor Management: Ensure contracts include identity requirements and that offboarding happens automatically when agreements end.

Controls Blueprint: Tying IGA to Frameworks and Regulations

Now that we’ve established the architecture and operating model, the next question a board or regulator will ask is, “How do these controls line up with recognized frameworks or laws?”

To answer that, we will now map your IGA program to relevant frameworks and regulations. This step is important because it shows that your initiative is anchored to external standards, it’s not simply a homegrown series of ideas. 

NIST Cybersecurity Framework 2.0 

NIST CSF 2.0 is one of the most known and respected playbooks for cybersecurity governance in the U.S. and abroad. From the framework, there are two areas especially relevant to identity.

• PR.AA (Identity Mgmt, Authn & Access Control): From page 19 of the CSF 2.0, this section expects that organizations will manage identity lifecycles, enforce MFA, apply least privilege, vault and rotate credentials, prevent toxic access combinations, and conduct periodic access certifications. In other words, this is the day-to-day work of IGA. These are tasks for which the IGA council should focus to achieve. 
• GV (Govern):  The “Govern” function is new in CSF 2.0 and makes identity governance explicitly a board responsibility. It expects boards to set risk appetite, assign roles and responsibilities, manage supply-chain identity exposure, and track metrics for continuous improvement. This is the board’s call for direct accountability.

DORA (Digital Operational Resilience Act)

Effective in Europe’s financial sector since January 2025, DORA requires companies to prove they can withstand ICT and third-party disruptions. For identity, that means demonstrating:

• Strong vendor access controls
• Rapid revocation of third-party accounts
• Tested incident playbooks and continuity plans

NIS2 Directive

NIS2 expands obligations well beyond finance, making identity and least privilege first-class controls across industries like healthcare, energy, and digital services. Boards need to show they’ve assessed supply-chain risks and put governance in place for all third-party and privileged access.

SEC Cyber Disclosure Rule

In the U.S., public companies must disclose material cyber incidents within four business days. This raises identity governance from a “back office” activity to a board reporting requirement. If an identity or access failure leads to a breach, the board must be able to demonstrate:

• They had visibility into identity risks
• They had tested playbooks for escalation and disclosure
• They can provide evidence of access governance at the time of the incident

Why This Matters

By explicitly mapping your IGA controls to NIST CSF and overlaying DORA, NIS2, and SEC requirements, you create a single story for auditors, regulators, and the board. Instead of a patchwork of policies, you can show:

• This control aligns with NIST.
• This same control satisfies DORA/NIS2/SEC requirements.
• Here’s the evidence (audit logs, certifications, revocations).

This reduces redundancy, simplifies reporting, and ensures the board can answer the toughest regulatory question: “Can you prove who had access, when, and why?”

Build the SoD/Access Policy Backbone

Once the architecture and governance model are in place, the next priority is to codify access rules; what combinations are allowed, what must be blocked, and how often they’re checked. This is your Segregation of Duties (SoD) and access policy backbone.

The SoD/Access Policy Backbone is a structured set of rules and guardrails that define who can do what across critical applications. It ensures no one person (or account) has too much unchecked power. 

Think of it like any other task. You want a separation of duties to ensure accountability and accuracy. You want different people creating a vendor and approving payments, or pushing code and approving its release. 

Core Components

The backbone of any effective identity governance program is built on a small set of practical components. These define where to focus, what rules to enforce, how exceptions are handled, and how often access is checked. Keeping this simple but structured makes it easier for teams to execute and for boards to oversee.

This backbone turns abstract “least privilege” into tangible, enforceable rules. It gives the board confidence that fraud opportunities are minimized, regulators evidence that toxic combinations are managed, and business leaders assurance that emergency access is possible without leaving permanent backdoors.

SaaS Sprawl Taming Plan (Fast Wins That Scale)

SaaS sprawl is no longer measured in the dozens or even the hundreds. Torii’s research shows enterprise organizations run an average of ~1,850 apps, far higher than the ~100–275 apps reported by Okta. For boards and executives, this is more than just a cost problem, it’s a governance and compliance challenge. 

Every new app brings new identities, new entitlements, and new opportunities for oversight failures.

The good news: taming SaaS sprawl doesn’t require boiling the ocean. A phased, 180-day plan delivers fast wins, scales to enterprise portfolios, and works for mid-market companies with leaner teams.

Phase 1 (0–30 days): Get Control of the Obvious

• SSO coverage for top 25 apps. Bring your most-used, highest-risk apps under single sign-on, and enable SCIM where available.
• Stop shadow IT invites. Put a hard stop on direct app invitations; enforce identity-provider onboarding only.
• Automate deprovisioning. Tie HR terminations and vendor contract ends directly to automated revokes. This closes the biggest “back door” first.

Who owns it: IT Ops/Identity team executes; App Owners and HR ensure onboarding/offboarding events are properly triggered.

Phase 2 (30–90 days): Address Hidden Risks

• Service account census. Inventory all non-human accounts, assign owners, and rotate high-risk secrets.
• Certify access for top-risk apps. Run your first round of certifications on the most critical applications. Purge orphaned accounts and close aging SoD violations.
• Normalize exception handling. Ensure temporary access is time-boxed, logged, and auto-expiring.

Who owns it: IGA Council oversees; App Owners validate; Internal Audit monitors exception debt.

Phase 3 (90–180 days): Scale and Mature

• Expand coverage. Push SSO/SCIM to cover ~80% of the portfolio, not just the top 25 apps.
• App-level SoD. Implement segregation-of-duties policies directly in SaaS apps that support it.
• Vendor portals. Bring supplier-facing access into the same IGA, SSO, and PAM flows as employees.
• Test response. Add ITDR detections across IdP/IGA/PAM, then run a red-team tabletop focused on identity misuse (we’ll cover more on IDTR in the next section).
• Refresh KPIs. Update the board-level KPI dashboard, set new targets, and establish next-year benchmarks based on progress.

Who owns it: CIO sponsors; CISO validates ITDR readiness; Board reviews new KPI trends.

Why This Matters

For enterprises, the scale (1,850 apps on average) makes SaaS governance a board-visible risk. For mid-market firms, fast growth means sprawl sneaks up faster than expected. This plan delivers:

• Quick wins in the first month (orphaned accounts gone, SSO on critical apps).
• Risk reduction in the first quarter (service accounts, certifications, vendor offboarding).
• Mature governance by six months (broad coverage, tested detection, refreshed KPIs).
  

ITDR Complements IGA (How They Work Together)

Even the best access policies can’t stop every attack. That’s why Identity Threat Detection & Response (ITDR) has become a critical partner to IGA. The two are designed to work hand-in-hand:

• IGA prevents issues by ensuring the right people have the right access at the right time.
• ITDR detects and responds when accounts, tokens, or policies are misused despite those guardrails.

Together, they close the loop: prevention on the front end, detection and containment on the back end.

Playbook Intersections (Examples)

• Suspicious impossible travel
  If a login shows up in two countries within minutes, ITDR auto-challenges the session. If it’s confirmed malicious, IGA policy revokes access while ITDR invalidates sessions and rotates tokens.
• Privilege escalation outside policy
  When a user suddenly gains admin rights outside approved channels, PAM cuts the session, IGA generates an exception ticket, and ITDR alerts the SOC while storing evidence for audit.
• Leaked secret detected
  If a secret (API key, token, password) shows up in a repo or monitoring feed, ITDR raises a high-severity alert. Then IGA/PAM rotate and re-issue credentials, forcing the owner to attest, targeting a mean-time-to-remediation of ≤ 7 days, compared to the DBIR’s 94-day median.
  

Why This Matters

For boards and executives, the key takeaway is that IGA and ITDR aren’t competing tools frameworks, they’re complementary layers of defense. IGA minimizes the number of doors into the enterprise; ITDR ensures that when a door is picked, the alarm rings and the lock is changed immediately.

This combination is what allows organizations to not only reduce breach likelihood but also meet audit and regulatory expectations for continuous monitoring and rapid response.

Executive ROI Model (Make Finance Love This)

Identity governance only resonates at the board level if it’s framed in terms of financial outcomes. For directors and CFOs, the question is simple: “What’s the return on this investment?” The answer comes in two parts:
1. Hard savings you can measure today
2. Risk-adjusted benefits that protect against tomorrow’s losses.

Hard Savings

• License reclamation through timely deprovisioning. Every orphaned seat costs money. By reclaiming SaaS licenses when users leave, you save directly: number of seats × monthly license cost × reclaimed seats. Finance teams see this as bottom-line savings.
• Audit prep reduction. Automated evidence collection and continuous certifications cut the hours spent on audit prep. Multiply saved hours by blended staff rates, then add in the reduced fines and fewer exceptions. That’s efficiency in dollars.
• Fewer privilege tickets. With cataloged roles and auto-approval guardrails, IT spends less time on access requests. The savings come in both reduced ticket volume and faster productivity for end users.
  

Risk-Adjusted Benefits

• Expected Loss Avoided. The formula: (Reduction in breach likelihood) × ($4.4M global average cost, per IBM). Regionalize where possible. Even modest improvements in likelihood reduction translate into millions of dollars in avoided loss.
• Ransomware containment and non-payment posture. Verizon’s 2025 DBIR shows that most organizations now decline to pay ransom. That makes response speed critical. Containing identity-driven ransomware quickly avoids secondary costs: PR damage, legal fees, downtime, and lost customer trust.
  

Time-to-Value

Boards don’t want ROI that takes years to materialize. Identity governance delivers visible results in 2–3 quarters if you focus on the right KPIs:

• Orphaned accounts down
• Time-to-deprovision reduced
• SSO/SCIM coverage up
• SoD backlog reduced

Each of these can be tracked quarter by quarter, giving executives clear evidence that the program is paying off.

Why Finance Should Care

• Direct savings (licenses, audit prep) show up in the P&L quickly.
• Risk-adjusted benefits protect against catastrophic losses that could wipe out annual earnings.
• Faster time-to-value means this isn’t a long-term “trust us” program, it’s measurable progress within the board’s reporting cycle.
  

Conclusion: From IT Project to Boardroom Priority

Identity Governance & Administration can no longer be treated as a back-office IT exercise. The data is clear: identity failures drive the majority of breaches, regulators on both sides of the Atlantic are raising the bar, and SaaS portfolios have exploded into the thousands of apps. What once felt like a technical detail is now a board-level governance issue, with financial, regulatory, and reputational consequences.

The blueprint we’ve laid out shows how to take control. It starts with a reference architecture that unifies prevention and detection. It moves through board-ready KPIs that let directors measure progress the same way they measure financials. It establishes a governance model with clear accountability, ties directly to NIST CSF 2.0 and regulatory overlays, and translates into fast wins against SaaS sprawl. Finally, it delivers a finance-ready ROI story that connects identity governance to both hard savings and avoided losses.

For boards, the next step isn’t whether to invest in IGA, it’s how quickly to elevate it into the governance agenda. For executives, the challenge is execution: embedding identity controls into everyday operations, measuring results quarter by quarter, and keeping oversight tight as the business grows.

The takeaway is simple: identity is the new control plane for digital business risk. Treating it as such not only reduces breach likelihood, but also positions the organization to meet regulatory demands, satisfy auditors, and protect shareholder value.

Appendix

Glossary of Critical Terms for the Enterprise IGA Blueprint

Access Certification (Access Review)

A periodic attestation by managers/owners to confirm users still need their current access; removals and exceptions are recorded as audit evidence.

Access Request Catalog (Catalog Roles)

A menu of pre-approved role bundles that users can request; low-risk items auto-approve within guardrails to reduce ticket load.

ABAC (Attribute-Based Access Control)

Authorization based on user/app/resource attributes (e.g., department, device posture), often layered with RBAC.

AD / Active Directory (incl. Entra ID)

Microsoft’s directory platforms that store identities, groups, and policies and act as core identity stores for many enterprises.

AI Identity & Data Guardrails

Policies that treat AI systems/agents as identities—governing what data they can access, which plugins/APIs they can use, and how their secrets are managed.

API Key / Token

A credential used by software and services (non-human identities) to authenticate to systems; must be issued, rotated, and revoked like user passwords.

App Owner

The accountable person for an application’s access policies, approvals, SoD rules, and certifications.

Audit Evidence / Evidence Locker

Time-stamped artifacts (logs, exports, screenshots, tickets, attestations) stored systematically to prove controls are operating.

Audit-Ready Pack

A pre-assembled set of policy, configuration, samples, and evidence for a specific control, prepared for auditors/regulators.

Auto-Revoke (Non-Response)

A rule that removes access if a reviewer does not complete a certification by the deadline.

Blast Radius (Business Impact)

The potential harm if a system or identity is compromised (financial, regulatory, operational); used to prioritize “top 50” critical apps.

Break-Glass (Emergency Access)

A tightly time-boxed, logged, and monitored elevation path used in emergencies; must auto-expire and be reviewed afterward.

CMDB (Configuration Management Database)

A repository of infrastructure/services metadata that helps discover machines, service accounts, and ownership.

Compensating Control

An alternate control that reduces risk when a preferred control (e.g., removing a SoD violation) is temporarily infeasible.

Credential Vaulting / Secret Vault

Secure storage for passwords, keys, and certificates, typically managed by PAM; supports rotation and access auditing.

CSF (NIST Cybersecurity Framework) 2.0

A widely used framework; this guide maps IGA to PR.AA (Identity/Access outcomes) and GV (Govern).

Deprovisioning (Termination Revocation)

Automated removal of accounts/entitlements when people leave or vendors/contracts end; measured as TTD.

Device Posture

Security state of a device (OS version, disk encryption, EDR present) used in Zero Trust access decisions.

Disclosure (SEC 8-K Item 1.05)

U.S. requirement to disclose material cyber incidents within four business days of determining materiality.

DORA (Digital Operational Resilience Act)

EU regulation for financial entities focusing on ICT/third-party resilience; requires strong vendor access governance and tested response.

Entitlement / Permission

A discrete right in an application (e.g., “Billing Admin,” “Export Data”) that should be role- or policy-managed.

Exception / Exception Debt

Temporary access granted outside standard policy; becomes “debt” if not time-boxed and auto-expired.

Expected Loss Avoided (ELA)

Risk ROI metric: (Reduction in breach likelihood) × (Average breach cost); used to quantify the financial impact of IGA.

FIDO2 / WebAuthn (Phishing-Resistant MFA)

Modern authentication standards using hardware or platform authenticators resistant to credential-phishing attacks.

Form 8-K (Material Cyber Incident)

The SEC filing used to disclose material cyber events; requires timely, evidence-backed decisioning on materiality.

Govern (NIST CSF 2.0 GV)

Framework function assigning board-level accountability for risk appetite, roles/responsibilities, supply-chain oversight, and metrics.

HRIS (Human Resources Information System)

The source of truth for workforce lifecycle events (hire, transfer, termination) that trigger provisioning/deprovisioning.

IAM (Identity & Access Management)

Operational systems that authenticate and authorize users (IdP, directories, SSO, MFA); IGA governs policy on top of IAM.

IGA (Identity Governance & Administration)

The policy/control plane that governs who gets what access, why, when, and for how long, with auditability (JML, requests, approvals, SoD, certifications).

IGA Council

Cross-functional working group (Security, IT, HR, Procurement, Legal, App Owners) that runs the program: SoD library, JML SLAs, vendor policy.

IdP (Identity Provider)

The service that authenticates users and issues assertions/tokens for SSO (e.g., Okta, Entra ID, Ping).

Impossible Travel

A detection signal where successive logins from distant locations cannot be legitimate given the elapsed time.

ITDR (Identity Threat Detection & Response)

Detection/response focused on identity systems and usage (token theft, anomalous privilege, lateral movement), with automated containment.

JEA / JIT (Just-Enough / Just-In-Time)

Least-privilege patterns that grant only the specific rights needed, and only for the time needed—often enforced through PAM.

JML (Joiner / Mover / Leaver)

Lifecycle processes that create, modify, and remove access based on HR or vendor events; must be automated and auditable.

KPI (Key Performance Indicator)

An outcome metric used to manage performance (e.g., orphaned accounts ↓80%, TTD ≤4h/24h).

KRI (Key Risk Indicator)

A forward-looking signal of risk (e.g., % privileged accounts without phishing-resistant MFA).

Least Privilege

Granting only the minimum access necessary to perform a task; cornerstone of Zero Trust and SoD.

Machine Identity (Non-Human Identity, NHI)

Service accounts, workloads, bots, CI/CD and API credentials that require ownership, rotation, and certification.

Materiality (Cyber Incidents)

A determination of whether an incident is important to investors; triggers SEC disclosure timelines.

MFA (Multi-Factor Authentication)

Authentication that requires two or more factors; phishing-resistant MFA (FIDO2/WebAuthn) is preferred for privileged access.

MTTR (Mean Time to Respond/Recover)

Average time from alert to containment/recovery for identity incidents; measured from system logs.

NIS2 (EU Directive)

EU directive expanding cyber obligations and enforcement across sectors; includes supply-chain and access governance expectations.

NIST CSF 2.0 PR.AA

Outcomes category covering identity management, authentication, access control, SoD, credential rotation, certifications.

OAuth 2.0 / OIDC (OpenID Connect)

Standards for delegated authorization and federated authentication, commonly used for modern SSO.

Offboarding (Vendor / Workforce)

The process of revoking all access and reclaiming licenses at contract end or termination; must be automated and evidenced.

Orphaned Account

An account without an active owner (often after turnover or vendor churn); a high-risk hygiene defect and core KPI.

PAM (Privileged Access Management)

Controls for high-risk/admin access: session brokering/recording, JIT elevation, vaulting and rotation for human and machine credentials.

PBAC (Policy-Based Access Control)

Authorization using policies that evaluate context (risk, device, location) at decision time.

Phishing-Resistant MFA

MFA that resists credential phishing and man-in-the-middle attacks (e.g., FIDO2/WebAuthn, platform passkeys).

Privilege Escalation (Outside Policy)

A user or service gaining higher privileges through unsanctioned paths; should trigger PAM cut-off and ITDR alert.

Provisioning / Reconciliation

Provisioning: creating accounts/entitlements from IGA to apps. Reconciliation: pulling actual app entitlements back to detect drift.

RBAC (Role-Based Access Control)

Authorization based on roles that bundle entitlements by job function; often combined with ABAC.

RACI (Responsible, Accountable, Consulted, Informed)

A responsibility model clarifying who owns what across board, executives, council, and operations.

Risk Appetite (Identity)

The level of identity/access risk the board is willing to accept, used to set targets and thresholds.

ROI (Return on Investment)

Financial returns from IGA: hard savings (licenses, audit hours) and risk-adjusted benefits (Expected Loss Avoided).

SCIM (System for Cross-domain Identity Management)

Open standard that automates account provisioning/deprovisioning across SaaS applications.

SaaS Sprawl

Rapid growth of applications and identities (often >1,800 in enterprises) that strains governance, offboarding, and SoD control.

SAML (Security Assertion Markup Language)

A federation standard used for SSO, especially with legacy or enterprise apps.

SEC Cyber Disclosure Rule

U.S. rule requiring timely disclosure of material cyber incidents and governance reporting; pushes identity oversight to the board.

Secret / Secret Rotation

Any credential (password, token, key) used by humans or services; rotation is the scheduled or event-driven replacement of that secret.

Secrets MTTR

Time from detection of leaked/compromised secrets to rotation/reissue; target ≤7 days.

Service Account

A non-human account used by applications or automation; must have a named owner, purpose, and rotation policy.

Shadow IT

Systems acquired or used outside official IT/IGA processes (e.g., direct SaaS invites); increases risk and audit scope.

SoD (Segregation of Duties)

Policies preventing toxic combinations of access (e.g., create vendor + approve payment) to reduce fraud/error.

SoD Library

A documented set of toxic-combo rules across finance, engineering, cloud ops, and data domains, seeded by audits and incidents.

SSO (Single Sign-On)

One identity to access many apps via federation (SAML/OIDC); enables centralized policy and telemetry.

Supplier / Third-Party Access

Governed access for non-employees (vendors, partners, contractors) that must follow the same IGA/PAM rules and automated offboarding.

Tabletop Exercise (Identity/Disclosure)

A rehearsal of incident detection, materiality decisioning, and disclosure—validates playbooks and timing (e.g., SEC 4-day rule).

Target Coverage (e.g., SSO/SCIM ≥80%)

A measurable adoption goal that prioritizes the highest-risk or highest-use apps first, then scales to the long tail.

Threat Telemetry (Identity)

Signals from IdP, IGA, PAM, and SIEM used by ITDR to detect anomalies (impossible travel, token theft, privilege surge).

Time-to-Deprovision (TTD)

Elapsed time from HR/vendor termination event to last access revoked; measured from system timestamps.

Time-to-Value (TTV)

Window (often 2–3 quarters) to show KPI improvements (e.g., orphans ↓, TTD ↓, SSO/SCIM ↑, SoD backlog ↓).

Token Invalidation / Session Kill

Automated response that terminates active sessions and revokes tokens after suspected compromise.

Top 50 Critical Apps

The prioritized application set (by blast radius and data sensitivity) used for initial control rollout, certifications, and SSO/SCIM onboarding.

Vendor Master

System of record for suppliers/contractors used to trigger onboarding/offboarding and to scope third-party certifications.

WebAuthn / Passkeys

Standards enabling passwordless or phishing-resistant authentication using device-bound or roaming authenticators.

Zero Trust (ZTA)

“Never trust, always verify” architecture: continuous, context-aware access decisions (identity, device, risk) with no implicit network trust.

Resources & Further Reading

Breach & Threat Landscape

• Verizon 2025 Data Breach Investigations Report (DBIR) — Executive summary (PDF)
  https://www.verizon.com/business/resources/reports/2025-dbir-executive-summary.pdf
  Key stats on ransomware prevalence, human element, 3rd-party involvement, and leaked secrets remediation timelines.
• Verizon 2025 DBIR (full hub)
  https://www.verizon.com/business/resources/reports/dbir/
  Landing page with links to the full report, snapshots, and visuals.
• DBIR Highlights Infographic (PDF)
  https://www.verizon.com/business/resources/reports/2025-dbir-executive-summary-infographic.pdf
  Quick scan of the year’s key trends.
• IBM Cost of a Data Breach 2025 (Main Report Page)
  https://www.ibm.com/reports/data-breach
  Summarizes global average breach cost ($4.44M) and AI oversight gaps (97% lacked AI access controls; 63% lacked AI governance policies).
• IBM Press Release (AI-specific findings)
  https://newsroom.ibm.com/2025-07-16-IBM-Report-Cybersecurity-AI
  Highlights AI-related security risks from the 2025 study.

Frameworks & Standards

• NIST Cybersecurity Framework 2.0 (Full Document)
  https://www.nist.gov/cyberframework
  Authoritative reference for governance and identity outcomes.
• NIST CSF 2.0 — PR.AA (Identity Mgmt, Authentication & Access Control)
  https://csf.tools/reference/nist-cybersecurity-framework/v2-0/pr/aa/
  Category page to map IGA controls.
• NIST CSF 2.0 — Govern (GV) Function
  https://csf.tools/reference/nist-cybersecurity-framework/v2-0/gv/
  Board-level governance expectations and outcomes.
• NIST CSF 2.0 FAQs
  https://www.nist.gov/cyberframework/faqs
  Helpful clarifications for board/Audit & Risk discussions.

Regulations & Oversight

• DORA (Digital Operational Resilience Act) — EIOPA Overview
  https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
  What’s in scope and what boards must evidence; in force since Jan 17, 2025.
• NIS2 — European Commission Press Release
  https://digital-strategy.ec.europa.eu/en/news/commission-calls-23-member-states-fully-transpose-nis2-directive
  EC opened infringement procedures against 23 Member States for missed transposition.
• SEC Cybersecurity Disclosure Final Rule (Release No. 33-11216)
  https://www.sec.gov/files/rules/final/2023/33-11216.pdf
  The source of the 4-business-day incident disclosure requirement (Item 1.05).
• SEC Fact Sheet — Public Company Cybersecurity Disclosures
  https://www.sec.gov/files/33-11216-fact-sheet.pdf
  Plain-English summary for directors and GC/IR.

Identity Threat Detection & Response (ITDR)

• Microsoft: Identity Threat Detection & Response (Overview)
  https://www.microsoft.com/en-us/security/business/solutions/identity-threat-detection-response
  High-level overview of ITDR.
• Microsoft Learn — Defender for Identity: ITDR Dashboard
  https://learn.microsoft.com/en-us/defender-for-identity/ops-guide/ops-guide-daily
  How teams operationalize detections and MTTR.
• Microsoft Learn — What is Defender for Identity?
  https://learn.microsoft.com/en-us/defender-for-identity/what-is
  Productized ITDR capabilities and scope.

SaaS Sprawl & App Portfolios

• Okta: Businesses at Work 2025
  https://www.okta.com/reports/businesses-at-work/
  App usage trends and average app counts by org size.
• Zylo: 2025 SaaS Management Index
  https://zylo.com/resources/guides/saas-management-index-2025/
  Portfolio size, category growth, and license utilization benchmarks.
• Torii Research (2025) (internal)
  Enterprise portfolios average ~1,850 apps. Contact Torii for methodology and briefing deck.

Machine / Non-Human Identities

CyberArk 2025 Identity Security Landscape
https://www.cyberark.com/resources/analyst-research/2025-identity-security-landscape
Source of the “machine identities outnumber humans 82:1” statistic.