I'm reviewing JumpCloud's pricing and structure for a potential deployment. The documentation frequently distinguishes between "systems" and "users" as two core object types that can be managed.
From a billing perspective, I understand these are separate licensed entities. However, I'm unclear on the functional distinction for administration. For example, if a developer needs access to a server (a system) via SSH, does that consume both a user license and a system license? Or is the system license just for the managed endpoint itself?
A concrete example would help: a company with 50 employees and 100 servers. How would these counts map to the two license types in practice? Is a "system" always a machine, or can it be another type of resource?
You've got the basic split right, but the SSH example is where it gets messy. In your scenario, you'd license 50 users and 100 systems. The developer is a user, the server is a system. Giving them SSH access ties the two together but doesn't create a third license type.
However, that system license is indeed just for the managed endpoint - a physical or virtual machine with the agent installed. It's not for other resources like databases or network gear, unless you're installing the agent on them, which is... unlikely. The real gripe is when you have contractors or service accounts that need system access, they still burn a full user seat. The pricing model assumes every human with access is a standard employee, which is rarely the full picture.
Just to add to what others might say - a system in JC is indeed always a machine (physical or virtual) with the agent. It's not like a network resource or a database. I think your 50 users / 100 servers example is spot on. But one thing that confuses me is how they handle shared systems like a kiosk or a lab computer - does each person that logs in need a user license? Or just the system? That part isn't clear to me from the docs. Did you find anything about that?
Great point about shared systems. That's a real edge case for their licensing model.
From what I've seen in their support forums, the user license requirement kicks in when an identity is centrally managed in JumpCloud. So if ten different people log into a single kiosk computer, and each of those people is a distinct JC user object, that's ten user licenses. The system itself is just the one license.
Some orgs get around this by creating a single, generic "kiosk user" account in JC for shared access, but then you lose individual accountability for logins and actions. It's a trade-off between license cost and security audit trails.
Has anyone tried that generic account route? The audit log must be a nightmare.
You've hit on the core abstraction right away. Think of it this way: a **User** is an identity (a digital representation of a person or service account), and a **System** is a thing that identity can access or log into (a computer, virtual machine, or server with the JC agent).
So for your developer and server example, yes, it consumes both licenses. You need one user license for the developer's managed identity, and one system license for that server you've enrolled. The SSH access binding is just a policy connecting those two licensed objects.
Your example of 50 employees and 100 servers maps perfectly: 50 user licenses, 100 system licenses. The "system" is indeed always a machine where you can install the agent. You wouldn't use it for a network switch or a SaaS application; those are covered by other JC features (like RADIUS or SAML) that still rely on those user identities.
The functional distinction shows up in the admin panel. You'll manage user settings (passwords, MFA, groups) in the Users section, and you'll manage machine-specific configurations (local user accounts, security policies, software installs) in the Systems section. They're separate but intertwined object types.
Design for failure.
The generic kiosk user idea is a classic example of letting the licensing tail wag the security dog. Sure, you'll save on user licenses, but you've just created a shared credential nightmare. Compliance frameworks will have a field day with that.
And don't assume that's a loophole JC hasn't considered. Their audit logs for system logins are tied to the authenticated user object. If you're using a single generic account, every login event from ten different people looks identical. So you traded a line item on your vendor invoice for a gaping hole in your accountability. Not a swap I'd make.
Test the migration.