Per Endpoint Versus Per User Models

What is the difference between per endpoint and per user models?

The difference between per endpoint and per user models is what the meter counts: per endpoint pricing charges for every protected device, while per user pricing charges for every person no matter how many devices they carry. Security vendors such as CrowdStrike, with its Falcon modules, often price per endpoint, while identity vendors such as Okta price per user, and many security platforms now offer both. The same protection across the same organisation can cost very differently under the two models, because the bill is driven by whichever thing you have more of. A workforce where each person uses a single laptop looks similar under both meters, but an estate full of servers, shared devices, kiosks, and mobile fleets balloons under per endpoint pricing, while a workforce of mostly light users with one device each can be cheaper per endpoint than per user. The meter, not just the rate, is a pricing decision.

This is an instance of the wider truth that how you are counted often matters more than the unit price. The full approach to interrogating a pricing model sits in the SaaS Negotiation Guide.

When does per endpoint pricing favour the buyer?

Per endpoint pricing favours the buyer when the estate has few devices per person and a clean, well managed device inventory. An organisation where most employees use a single managed laptop, with relatively few servers and shared devices, will often pay less under a per endpoint model than under a per user model that charges full price for every person regardless of their light footprint. Per endpoint also rewards good device hygiene, because every retired or duplicate device you remove from the count lowers the bill directly, which gives the buyer an ongoing lever that a per user model does not. The risk in per endpoint pricing is scope creep on the device side: servers, virtual machines, containers, mobile devices, and IoT endpoints can all be pulled into the count, so the buyer must define precisely what counts as a billable endpoint before agreeing the model.

When does per user pricing favour the buyer?

Per user pricing favours the buyer when each person operates many devices, because one charge then covers a laptop, a desktop, a phone, a tablet, and any virtual machines that person uses. Estates heavy in servers, developer workstations, or multi device users are usually cheaper per user, and per user pricing also simplifies forecasting, because headcount is easier to predict and govern than a fluctuating device count. The table below summarises which model tends to win for which estate.

For how a per endpoint security vendor structures its bundle, read Falcon modules and the bundle math, and for the per user identity comparison, see Okta per user pricing and the tier question.

Why do vendors default to the model that suits them?

Vendors default to the model that suits them because they can see your estate shape and quote the meter that maximises their revenue for it. A vendor selling into a server heavy environment may lead with per endpoint pricing precisely because the endpoint count is high, while another may lead with per user to capture light users at a full rate. This is not deception, it is commercial design, and the counter is to refuse to accept the proposed meter as a given. The security fear sell compounds it, because buyers under pressure to close a coverage gap often accept the first model offered rather than test the alternative. The buyer who models both meters against their real estate, and who treats the model choice as negotiable, removes the vendor's information advantage and frequently finds the larger saving sits in the meter rather than the rate.

How do you negotiate the model, not just the rate?

You negotiate the model by quoting both meters against your own inventory, presenting the cheaper one as your baseline, and asking the vendor to match or justify the difference. Bring a precise count of endpoints and users, calculate the cost under each model at the offered rates, and lead with the configuration that favours you. Where a vendor only offers the unfavourable meter, use the alternative as leverage on rate, since a credible willingness to evaluate a competitor on a better model is real negotiating power and the threat only works when it is genuine. Lock whichever model you choose at the SKU level, define exactly what counts as a billable unit so the count cannot drift, and secure reduction rights so retiring devices or reducing headcount lowers the bill. The model decision is the one to get right first, because no discount rescues a deal struck on the wrong meter.

A worked example of choosing the meter

Consider an indicative example. A technology company with a large developer population is quoted endpoint protection on a per endpoint basis, and the count looks alarming because every engineer runs several machines and the server fleet is large. Rather than negotiate the endpoint rate, the buyer models the same coverage per user and finds the user count is a fraction of the endpoint count, making per user dramatically cheaper for its estate. It presents the per user model as its baseline, uses a credible competitive evaluation to hold the rate, defines billable users precisely, locks the model and rate at the SKU level, and secures reduction rights. The saving comes almost entirely from the meter, not the discount. These figures are indicative, but the lesson is general, and choosing the right model lands the buyer inside the 10 to 30 percent savings disciplined negotiation typically produces, by published market estimates.

What to do next

Before you accept a security or identity quote, model both per endpoint and per user against your real estate and negotiate the meter that favours you. The renewal mechanics are covered on the SaaS renewal negotiation service, and the full buyer method runs through the SaaS Negotiation Guide.

Last reviewed November 2025