Recently I had some conversations with both vendors and customers about licensing models for IAM (Identity and Access Management) software. Historically, most licensing models were (and still are) based on the number of users, typically “named” users (rather than “concurrent” users). License models based on the number of concurrent users are rather unusual for IAM.

Nowadays, I observe some shift towards models that are based on the number of connections or even processor-based. The number of connections is a metric that shows up in federation products, where the connection typically is defined as “a connection from the federation hub to a target system, either Identity Provider or Service Provider”. However, vendors might also focus on “concurrent connections” in the sense of users federating. I have also seen approaches that are about billing per connection, i.e. based on the actual use of a federation service, in cloud-based offerings.

I also have been involved in discussions between customers and vendors about dealing with externals (contractors, clients, vendors, etc.). When looking for an Identity Provisioning or Access Governance solution with focus on the employees, a licensing model based on named users is straightforward. It is predictable. However, once the number of external identities grows, the question of changing the metric arises. Should an external user that typically has somewhat limited access cost as much as the regular, internal user? I have seen different approaches ranging from the full fee to a percentage of the regular user fee or even flat rates for external users.

Finally, there is the discussion about classical license-plus-maintenance models versus subscription-based models without the initial fee but a constant annually rate to pay.

So what is the best model? Honestly, I do not know what the perfect model is. I even doubt that there is the perfect model for licensing. However, both vendors and customers should concentrate on the characteristics of a “good” licensing model, besides the fact that the vendor wants to earn as much as he can and the customer wants to pay as little as possible. These are, from the customer perspective

  • Predictiveness
  • Flexibility for adopting the model as needs change
  • Flexibility to change the vendor
The first one probably is the most important one. Customers need to be able to calculate the cost in advance. That works well for flat rate models, but it does not work for models where either the user base can grow massively – think about the Identity Explosion – or which rely on the use of a service. Models that are based on a flat fee for external users, an overall flat fee (does not work well for vendors in most cases) or other factors like the number of connections to IdPs and SPs fulfill that requirement. Also processor-based licensing works quite well because it scales slowly and in a predictable manner.

The flexibility to adopt models as needs change – by both scaling up and scaling down – is another important factor. However, this again is about predictiveness. Adding new groups of users, new systems, etc. must be predictive. Doing that right can be rather attractive for customers, when they can start small with a one or two partner case and then add other federation partners or systems subsequently, with a fixed cost per added partner/system.

The flexibility to change the vendor clearly is not in the interest of the vendor, but the customer. The initial license fee is an inhibitor for change. When you have to pay 500,000 € or US$ in advance just for licenses, it is much more difficult to build the business case for switching to another vendor than when relying on subscription-based models with a lower “entry fee”.

I recommend both vendors and customers to consider these criteria when looking at pricing models and rethinking existing business models. The most important question is: will success become too expensive? Or, in other words: will the Identity Explosion destroy my calculation? Overall, I see a shift away from purely user-based licensing in most disciplines of IAM. Dealing with more types of users requires different answers.