Figma Just Started Logging Out Shared Logins. Account-Sharing Enforcement Is Coming for the Rest of B2B SaaS.

Every SaaS company with per-seat pricing has spent the last few years building tooling to catch the opposite problem: seats nobody uses. Usage dashboards, dormant-license alerts, right-sizing offers at renewal — we've covered that side of seat churn in detail. What almost nobody has built tooling for is the inverse: one paid seat, several unpaid people using it. That's finally starting to change, and the company that just made it visible is Figma.

That number comes from streaming, not SaaS. But the mechanism it describes — enforcement creates a forced decision, and some share of the people facing that decision will leave instead of pay — is identical wherever a product lets more people use it than the number of licenses sold for it. B2B tools are only now starting to find that out for themselves.

What Figma actually did

Starting in late August 2026, Figma users on Professional team plans began reporting something new in the community forum: their sessions were getting logged out, seemingly at random, with no explanation in the product itself. Figma's community support team gave a direct answer on August 27: "It sounds like multiple team members may be using the same Figma login," and warned that older sessions "may be logged out as other team members sign in."

The enforcement basis Figma cited is section 2.4b of its Terms of Service, and support described the detection method in deliberately general terms — the product "looks at a range of signals that may indicate suspicious activity," rather than enforcing a fixed concurrent-session limit. Users can see their own active sessions under Account → Security, with device and rough location attached to each one, though support noted a VPN can throw the displayed location off. The fix support recommended was the obvious one: each person gets their own account, added to the team with a Full, Dev, or Collab seat.

None of this is a security feature. Figma didn't frame it as one, and nothing in the thread mentions account suspension or a ban. It's a seat-enforcement feature wearing a security-sounding name, and it's a preview of what's coming to a lot more B2B tools that charge per seat but have never technically prevented one login from serving several people.

Why this is structurally the same problem Netflix solved

Netflix spent years treating password sharing as an acceptable cost of growth — the 2017 tweet "Love is sharing a password" was literally the company's own marketing. The crackdown that followed wasn't subtle: a device that hadn't connected to the account's home network in 30 days lost access, full stop, unless the primary account holder paid for an extra member slot.

The churn-versus-conversion tension that played out afterward is the same tension every B2B SaaS company enforcing seat logins is about to walk into. On one side, Horowitz Research's 2024 survey found that 52% of streaming viewers had canceled or lost access to at least one service in the prior year, and close to 3 in 10 of those cancellations cited being unable to share or borrow a login as a contributing factor. On the other side, MoffettNathanson's analysis of Netflix's own numbers found that converting even a quarter of password-sharers into paying accounts would add 6.8 million subscribers and $567 million a year in revenue. Both things were true at once. The crackdown lost some people and created meaningfully more paying ones.

Password-sharing crackdowns weren't the only driver of that jump — price increases and perceived lack of value were cited more often. But the direction is the point: tightening access that was previously free creates measurable cancel intent, on top of whatever baseline churn already existed. A B2B SaaS company turning on seat enforcement for the first time should expect the same shape of response, scaled to however many of its accounts are currently sharing logins.

Seat sharing isn't the same leak as seat waste

It's worth being precise about which problem this is, because the fix for one makes the other worse.

A right-sizing offer — "renew at your actual active seat count" — is the correct response to seat waste and the worst possible response to seat sharing. One shrinks a renewal to match real usage; the other would just legitimize a workflow built on splitting one license five ways. These need separate detection and separate playbooks, even though both eventually show up in the same place: a seat count that doesn't match reality.

How the detection actually works

Figma didn't publish its exact ruleset, and for good reason — publishing the threshold tells people exactly how to stay under it. But the general approach, which is also how most session-abuse detection works in consumer streaming, comes down to a handful of signals layered together rather than any single hard rule:

• Concurrent sessions from distinct devices. Two active sessions from different device fingerprints at the same time is a weak signal alone — people genuinely use a laptop and a phone — but a sustained pattern of 3-4+ concurrent devices is a much stronger one.
• Geographic distance within an implausible window. A login from one city followed by a login from another more than a few hours' travel away, minutes later, is the classic shared-credential fingerprint.
• Session handoff cadence that doesn't match one person. One account logging in and out on a predictable rotation — morning on one device, afternoon on another, evening on a third — looks different from one person's natural usage pattern across their own devices.
• IP/ASN diversity over a short period. Credentials used from several unrelated residential or corporate networks within days, rather than the handful an individual typically touches (home, office, phone carrier), is a strong composite signal even when any single login looks ordinary.

None of these signals is reliable in isolation — VPNs, travel, and shared office networks all produce false positives on their own. That's exactly why Figma frames it as "a range of signals" rather than a rule, and why building this well requires tolerance for ambiguous cases, not a hard cutoff.

How to roll this out without a Netflix-style backlash

Make usage visible before you make it painful

The accounts most likely to react badly to a surprise logout are the ones who had no idea anything was ambiguous about their setup. Show the account admin their own session activity — which seat has how many concurrent logins, from how many distinct locations — for a few weeks before enforcement changes anything. This mirrors exactly what we recommend for seat waste: the side that raises the issue first controls the framing. If you log someone out with no warning, your framing is "we caught you." If you show them a month in advance, your framing is "here's what we're seeing, want to add a seat before this changes."

Build a one-click path from "logged out" to "paying"

Figma's support thread doesn't mention an in-product upsell at the moment of logout — the recommended fix is a generic "add seats to your team." The conversion math from the Netflix data only works if the upgrade path is immediate and frictionless. A sharer who gets logged out and has to find pricing, start a new conversation with procurement, and wait a week for approval will often just stop using the product instead. One that gets a direct "add your own Full seat for $X/month" button at the exact moment of the lockout converts at a meaningfully higher rate, because the decision is made while the need is still acute.

Treat the lockout like a cancellation moment, because functionally it is one

The person staring at a logged-out screen is making the same decision as someone on your cancellation flow's confirm page: pay to keep access, or walk away. Most teams don't apply any of the same thinking to it — no reason captured, no segmented offer, just a generic paywall. Ask why they were sharing (cost, never realized it wasn't allowed, temporary project need) the same way a cancel survey asks why someone's leaving, and route the response accordingly: a cost-sensitive sharer might convert on a discounted individual seat; a project-based one might just need a short-term add-on rather than a permanent upgrade. Treating every locked-out sharer identically wastes the same conversion opportunity that a blanket discount wastes on a cancel page — which is the exact mistake we've written about in the context of matching retention offers to cancel reasons.

Phase the enforcement, don't flip a switch

Figma's own forum shows the cost of getting the rollout pace wrong — by late September, support was walking back some of the friction ("an update that should help reduce interruptions"), after users had already spent a month complaining publicly. A staged rollout — warn, then soft-enforce with a grace period, then hard-enforce — gives you time to tune false-positive rates before they become public complaints, and gives legitimate multi-device users room to adjust without ever hitting a wall.

None of this means you should leave seat sharing unaddressed if your pricing is per-seat. Left alone, it's a permanent, silent leak with no expiration date — unlike seat waste, which at least eventually shows up in an audit. The conversions available when you fix it properly are real money, demonstrated at Netflix's scale by MoffettNathanson's own numbers. The only real mistake is treating detection as the finish line instead of the start of a conversion flow. If you're already running a CancelFlow cancellation flow to capture reasons and route offers when someone tries to leave, the exact same logic — ask first, offer the matched response, don't force a blunt binary — is what turns a seat-sharing crackdown from a PR problem into new revenue. You can model what even a modest seat-sharing conversion rate is worth to your ARR with our churn calculator before you build anything.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.