Why we moved KeyScaler to usage-based pricing

Every security leader we talk to is asked some version of the same question during budget season: how many devices will you have next year, and what will they be doing?

It’s a reasonable question. It’s also, in most cases, unanswerable.

A medical device manufacturer doesn’t know how many units will clear regulatory approval in a given quarter. An automotive supplier doesn’t know which programs will scale and which will be shelved. A utility running a substation modernization doesn’t know how many sensors, gateways, and controllers will end up in the final design until the design is finished — and the design is never quite finished. Add the pace at which non-human identities are proliferating across OT, cloud, and increasingly agentic workloads, and the forecast becomes less a plan than a guess with a purchase order attached.

For years, the machine identity market asked customers to make that guess anyway. Buy a block of devices. Commit to a count. Hope you were close. If you overestimated, you paid for capacity you never used. If you underestimated, you either went back for an unplanned procurement cycle or you left devices unmanaged — which is the worse outcome, and the one auditors tend to notice.

We think that model is backwards. So we changed it.

Pay for what you do, not what you projected

KeyScaler is moving to a usage-based model. Instead of licensing a fixed device count, you draw from a pool of credits that are consumed by the operations you actually perform — provisioning an identity, rotating a credential, enrolling a certificate, enriching a device record with vulnerability and SBOM intelligence.

The shift sounds like a pricing change. In practice, it’s a change in what you’re allowed to do with the platform.

Under a device-count license, every new use case is a negotiation. You have the platform, but the capability you want to try sits behind a different SKU or a bigger commitment, so you don’t try it. Usage-based pricing removes that friction. The entire capability set is available from day one. You can run a proof of concept on a new product line without amending a contract. You can extend governance to a class of devices you hadn’t considered when you signed. You can turn on AI-driven enrichment across your fleet, see what it surfaces, and decide whether the intelligence is worth what it costs — with the actual numbers in front of you rather than a vendor’s estimate.

That’s the accessibility argument, and it matters most for the organizations that have historically been priced out of proper machine identity governance: the teams with ten thousand devices rather than ten million, who face the same regulatory expectations as their largest competitors and a fraction of the budget to meet them.

Transparency is a security requirement, not a billing feature

There’s a second reason we made this change, and it has less to do with commercial flexibility than with what our customers are now accountable for.

The buyer for machine identity has moved. It used to be an OT security manager or an embedded engineer solving a technical problem. Today it’s a CISO or a compliance officer who has to produce evidence — device inventory, lifecycle attestation, proof that credentials were issued, rotated, and revoked on a defensible schedule. FDA premarket submissions, NERC CIP audits, automotive OEM supplier requirements, and the EU Cyber Resilience Act all converge on the same demand: show your work.

A consumption model produces that record as a by product. Every credit drawn corresponds to a real operation against a real device. The usage ledger and the audit trail are the same artifact. You can see which parts of the fleet are consuming identity operations, which are dormant, and where governance coverage is thinner than the org chart suggests. That visibility is useful to a finance team. It is considerably more useful to whoever has to sign the attestation.

Transparency, in other words, isn’t a courtesy we extend at invoice time. It’s the same discipline the platform exists to enforce.

The modern shape of the problem

The device estate has stopped behaving like an asset register and started behaving like infrastructure — elastic, ephemeral, and increasingly populated by identities that no human provisioned. Agentic systems will accelerate that. The number of non-human identities in a typical enterprise is already growing faster than anyone’s ability to forecast it, and the gap is widening.

Static licensing was built for a static estate. It doesn’t survive contact with what’s coming.

Usage-based pricing is our answer to that, and it’s a straightforward one. Scale up when your programs scale. Scale down when they don’t. Turn on the capabilities you need when you need them. Pay for the operations you actually ran, and hold onto the evidence that you ran them.

You shouldn’t need to predict your device count to secure your devices. Now you don’t.

If you would like more information, fill out the form below and someone will be in touch to discuss what this pricing model could look like for you.