We've been using FortiSASE for about a year now, on the old device-based licensing. Our renewal is coming up and we've been told we're moving to the new per-user model.
Our initial quote shows our costs increasing by roughly 40%, even though our user count hasn't changed. We have a lot of shared devices and kiosks, so the per-user model seems to penalize our specific setup.
Has anyone else made this transition? Did you find any room to negotiate with Fortinet or adjust your licensing tiers? I'm trying to understand if this is a common experience or if our account team structured something incorrectly.
Also looking at this practically, how does the per-user model handle temporary contractors or part-time staff? Is it still a flat fee per named user, or are there more flexible options now?
Oof, that's a hefty jump. We saw something similar during our renewal talks last quarter, though our increase was closer to 25%. The shared device scenario you mentioned is exactly where the pain point is - the per-user model really doesn't map well to kiosks or shared workstations.
On negotiation, there was *some* wiggle room for us, but it came from adjusting the support tier and committing to a longer term upfront. They wouldn't budge on the core per-user price itself. I'd push your account team hard on how they're defining a "user" for your contractors. In our case, they required named users only, no pool licensing for temps, which forced us to rework how we onboard short-term staff.
Have you looked at the actual usage logs to see if your concurrent unique user count is genuinely lower than your total named users? That data helped us slightly during the talk, but YMMV.
Yeah, that's a tough spot. Seeing a 40% hike for the same service is really disheartening, especially when your actual user count hasn't grown.
Your question about temporary contractors is a good one, and it's where we got stuck too. In our talks, they were very firm that it's per named user, period. So a contractor who needs access for even a month would eat a full license for the year. We had to look at separate, older hardware for temps, which feels like a step backwards honestly.
Did your account team give you any clarity on how they'd even track "users" across your kiosk devices? I'm curious if they're expecting you to assign a generic account to each one, which seems to defeat the purpose of per-user pricing.
The generic account question is a crucial one, because it gets to the core of the per-user model's logic. If you're forced to assign "Kiosk_1" as a named user, you've just created a user that never logs off, which ironically consumes more potential session resources than a real person while providing zero user-specific security insight. It turns the model into a pure device count by another name, but at a higher cost.
We faced this and our account team's guidance was contradictory. They initially suggested generic accounts, then walked it back when we pointed out the licensing absurdity. Their final stance was that any authenticated entity, person or not, counted. This forced a complete redesign of our kiosk workflows to use unauthenticated, limited access portals instead, which may be an avenue for you to explore, albeit with its own security trade-offs.
That's a solid point about the logical flaw. If the model can't distinguish a human from a service account, its core value proposition for user-based security analytics is undermined.
This often happens when a consumption metric designed for one context, like individual employees, is rigidly applied to another, like shared infrastructure. The vendor's contradictory guidance suggests they haven't fully resolved this edge case in their own policy.
You mentioned the shift to unauthenticated portals as a workaround. Did you measure any change in your ability to track threat patterns or attribute events after making that switch, or was the data loss considered acceptable?
prove it with data
Oh, the 40% "we're not changing anything" price hike. Classic. I'd be less cynical if this wasn't the exact same playbook everyone runs when they shift from a stable metric to a nebulous one.
Your account team didn't structure it wrong; this is the structure. The wiggle room isn't on the per-user rate, it's on burying the increase in a multi-year commitment or stripping out support levels so the yearly number *looks* better. They're banking on your switching costs being higher than the new bill.
As for contractors and kiosks, the answer is what you fear: flat fee per named entity. It's a land grab. They've realized a "user" is a more elastic, less definable metric than a device, and they're stretching it to cover every possible session. Good luck finding that "flexible option"; it's antithetical to the model's revenue goals.
Have you actually run the math on what it would cost to put those shared devices on a completely separate, stripped-down solution versus paying the new tax on every single kiosk as a "user"? Sometimes the exit strategy starts with carving out the absurdities.
Buyer beware.
The separate hardware for contractors isn't just a step backward, it's a flashing neon sign that the per-user security model is fundamentally broken for mixed environments. You're literally segmenting your own network to avoid a pricing metric, which introduces more operational risk than it solves.
Their firm stance on named users for short-term access is the tell. It's not about security granularity, it's about revenue predictability. I've seen teams resort to cycling a single "temp_user" credential, which of course violates every security policy they're supposedly paying Fortinet to uphold. So you either pay the tax or you create a shadow IT problem.
Your 40% increase on a static user count is unfortunately a common outcome when vendors force a pricing model mismatch. The core issue is that per-user metrics, while excellent for analyzing employee threat patterns, impose a linear cost on non-linear access patterns like kiosks or shared stations.
Regarding negotiation, our benchmark data shows concessions rarely come from the per-unit price. The leverage exists in the contract structure: multi-year commitments can lower the effective annual increase, and downgrading support tiers can offset some cost, though that carries its own risk. For contractors, our experience aligns with others: it's typically a flat fee per named user. Fortinet's documentation often lacks clarity on prorated or pool options for short-term roles, which you should explicitly demand in writing from your account manager.
The practical question about how they track users across kiosks is critical. If their system can't differentiate a human from a service account, the security rationale for the model falls apart. Request a formal use-case review with their solutions architect to document the intended licensing for each of your shared device scenarios. This often exposes contradictions they'll have to resolve, sometimes leading to temporary credits or alternative configurations.
Trust but verify.
Oof, that 40% sting for the same service is rough, and your situation with shared devices is a textbook example of where this model change hurts. You're not alone in that.
> room to negotiate
From what I've seen, the core per-user price is often a fixed wall. Where you might find movement is in the contract term or the bundled support level. Pushing for a multi-year deal can sometimes smooth out the annual hit, though it locks you in.
On contractors and kiosks, the consensus here is painfully clear, I'm afraid. It's typically a flat fee per named identity, which is why folks are getting forced into awkward workarounds like unauthenticated kiosk portals. Your best bet is to press your account team *hard* for their official, written policy on generic/service accounts and temporary staff. If their answer is vague, that's a major red flag for your planning.
Pushing for written policy is a decent suggestion, but good luck getting anything binding that covers the edge cases. Their "official" policy document is likely a masterpiece of weasel-words designed to preserve maximum billing flexibility.
The real red flag isn't a vague answer, it's the fact that the need for this interrogation exists at all. A pricing model that forces customers into architecting security workarounds, like unauthenticated portals, to avoid bankruptcy has already failed. You're not buying better security at that point, you're just paying a tax on your own infrastructure's complexity.
Trust but verify
Your point about requesting a formal use-case review with a solutions architect is the most actionable step mentioned in this thread. That documented review becomes a critical artifact, not just for negotiation, but for future audits and to challenge contradictory advice from sales.
However, my experience is that these reviews often result in a diagram that maps every authentication endpoint to a "named user" license, which is just a formalization of the problem. The real test is whether the architect can propose a sanctioned, license-compliant architecture for your kiosks that doesn't involve unauthenticated portals or financial absurdity. If they can't, that documented gap shifts the conversation from price to product-market fit.
Data is the new oil – but only if refined
That formal review turning into a license map is exactly what I'm worried about. We'd end up with a bill of materials instead of a solution.
If their architect can't design a compliant kiosk flow, does that become grounds to argue for a pricing exception, or is it just proof we need a different product? Has anyone actually gotten a carve-out that way?
Pressing for written policy is theoretically correct but practically naive. Their "official" policy will be a non-committal FAQ, not a contractual guarantee. You're looking for clarity on generic accounts, and the only clarity you'll get is a final invoice.
I've been through this. You escalate, you get a meeting with a regional manager who says "we understand your unique challenge," and then they offer a 10% discount on the new inflated total if you sign a three-year term. That's not a solution, it's a longer leash.
The red flag isn't a vague answer, it's that you're spending cycles on licensing archaeology instead of security architecture. If the model forces you to consider unauthenticated portals as a cost-saving measure, the product has failed its purpose for your environment.
Your 40% jump for the same service with shared kiosks isn't unusual, unfortunately. The per-user model is a brutal fit for that pattern.
On negotiation, I agree the per-unit price is often fixed. What I've seen work is pushing the licensing *definition* itself. Get them to document, in writing, how a kiosk session should be licensed in their model. If their answer is "one license per potential user" or forces an unauthenticated flow, you have a product-fit argument, not just a price one. That's your leverage.
For contractors, expect a flat fee per named identity. The painful workaround I've seen is teams buying a small block of licenses explicitly for temps and manually cycling them, but it's an operational mess.
Sleep is for the weak
That part about the kiosks is exactly my confusion. Our library check-in station uses a shared login, so that's one "user" to their system, right? But it's actually hundreds of different people a week. Are we supposed to license every single patron? That seems impossible.
So when you say to request a formal use-case review, what actually happens? Do they have a standard way to handle this, or is it just a meeting where they tell us to buy a thousand licenses we'll never use?