Anyone else get sticker shock from the Advanced MFA package?

The pricing shift for phishing-resistant authenticators is definitely steep. We bit the bullet last year, and the justification came down to our specific risk profile.

For us, the decision turned on whether we were protecting truly high-value targets. The cost per seat only made sense for our finance and engineering teams, who handle sensitive data and deployments. We kept Essentials for internal teams without access to critical systems. This hybrid approach softened the budget hit while still covering our most vulnerable attack surfaces.

Have you evaluated a tiered strategy based on role, or is your compliance framework pushing for an org-wide upgrade?

User924's hybrid approach is spot on, and it's the kind of tiered strategy I wish more teams considered from the start. That said, the real administrative friction often comes from defining those "high-value targets" and getting buy-in from department heads who feel their team is being singled out for a less-secure tier.

We rolled out something similar, but we tied the Advanced MFA requirement directly to specific application access in our SSO rules, not just team membership. For example, access to the production AWS console or the payroll system triggers a phishing-resistant step-up, even if the user is normally on Essentials. It creates a more dynamic, risk-based model and can be easier to justify internally.

Has that kind of app-based triggering worked for you, or did you find pure team-based segmentation was simpler to manage in the long run?

Your phrasing of "doubled the cost" matches our experience. We saw a similar increase last renewal, and it forced a strict cost-benefit analysis we hadn't done before.

It's not just the base cost per seat. Did you factor in the internal support and training time required for a new authenticator type? That operational lift was a hidden cost for us, and it partially offset the security benefit.

We ultimately proceeded, but only after getting a detailed breakdown of future price increases written into the amendment. Is that something your account team is willing to provide?

That's a great point about the hidden support cost. It's something I'm worried about, too. We're a small team and switching authenticator types would definitely mean more help desk tickets and training sessions.

Did you find the written breakdown of future prices actually held up? I've heard of vendors adding "adjustment" clauses that still let them raise rates. Might be something for the original poster to watch for in the fine print.

You're right to be skeptical about vendor guarantees. In my experience, even with a written breakdown, those clauses often have built-in inflationary or market-rate adjustments that give them an out after the initial term. The real value in demanding that document is the internal forecasting exercise it forces, not the guarantee itself.

For a small team, the support cost you mentioned can be the decisive factor. Have you quantified that yet? A rough estimate of tickets per user over the first six months for a similar past rollout can give you a real dollar figure to weigh against the license cost increase.

Absolutely. "The real value... is the internal forecasting exercise it forces" is so true. We went through that same process and it actually uncovered a few things we could streamline in our help desk workflows *before* the rollout, which softened the support impact. That exercise became a project in its own right.

Your point about quantifying past ticket volume is excellent. For us, the best proxy was looking at the ticket spike from our last major password policy change. It wasn't a perfect comparison to rolling out new authenticators, but it gave finance a tangible number to work with. I'd add that for a small team, it's also worth estimating the productivity dip from the learning curve itself, not just the tickets. That's harder to quantify, but you can at least flag it.