How to Set Up a Cursor Team (Plans, Invites, SSO & MDM)

Creating a team takes one flow, whether you are starting fresh or upgrading an existing account. Name the team, pick a billing cycle and invite members; you pay pro-rata for who is active, not for fixed seats. Domain matching at the end lets verified teammates join on their own.

1. 1New users: visit cursor.com/team/new-team to create an account and team in one flow.
2. 2Existing users: open your dashboard and click Upgrade to Teams.
3. 3Enter a team name and select monthly or annual billing.
4. 4Invite members by email; charges are pro-rated for time each person is on the team.
5. 5Optional: enable domain matching in team settings so verified teammates with matching email domains can join without a direct invite.

The sequence above is worth reordering slightly. If SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. is anywhere in the plan, verify a domain before the invites go out, since domain verification is the prerequisite both for SSO and for the domain-matching toggle at the end of the flow. Invites work either way. What you avoid is running two membership paths at once while a shareable invite link, which carries a long expiry and works for anyone holding it, is still in circulation.

Domain matching is convenient and it is also, quietly, a spending decision. Every self-join adds a billable seat, so on a big verified domain you are trusting the domain instead of approving each person. Restricting invites to verified domains does the opposite job, blocking invitations sent outside your domains.

The other thing to check before inviting contractors: a Cursor account can belong to only one team at a time. Anyone already in a client's Cursor team has to leave it before they can join yours. Ask them to check the week before, not on the kickoff call.

Invite in waves rather than all at once.

Not for a technical reason. A first wave of ten surfaces the proxy and identity problems while you still have the attention to fix them, and it leaves you ten people who can answer questions for the next forty.

SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. (SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition.) is optional at setup but is the standard path for security review: it automates onboarding and offboarding through your identity provider. Configure it after the team exists from the admin dashboard. Teams and Enterprise tiers support SSO; pair it with enforced Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. before you scale seats.

Timing is decided by what SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. sits between. Domain verification has to exist first, and SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. later requires an active SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition. connection, so SSO gates the whole identity path whether or not you want it on day one. That argues for doing it during setup: the work is the same size later, against more accounts.

Under a dozen engineers with no identity provider already in place, SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. is mostly ceremony, and domain matching covers the join path with far less setup. It does nothing for offboarding, which is the trade. Above that size, or anywhere a security team signs off on tooling, I would treat SSO as non-optional and configure it before the first invite.

Configuring SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. and enforcing it are separate switches, and the order matters more than it looks. Sign one test user in through the identity provider, confirm they land in the right team, then enforce. The other way round means finding a mapping problem with everybody already waiting.

Cursor bills per active user, not pre-purchased seats. Add or remove users anytime; new members are charged pro-rata for their remaining cycle. If a removed user consumed any credits, their seat stays occupied until the billing period ends. Your renewal date does not move when you change headcount.

That mechanic catches people out twice over. A mid-cycle offboarding saves nothing this month, since the seat stays occupied to the end of the period, which makes seat trimming a next-invoice lever rather than a this-invoice one. And because the renewal date holds, a team that doubles in March pays a pro-rated top-up against its original invoice instead of starting a fresh cycle at the new size.

Monthly against annual is probably the only billing choice here worth deliberating, because the 20% annual saving comes with a commitment for the year. Everything else on this page adjusts pro-rata within days.

That callout has a sequencing catch. The team cannot run with zero paid members and it cannot run without an admin, so while yours is the only account on it your seat is load-bearing. Invite the first paid user, confirm they are active, then change your own role.

Download builds for every platform at cursor.com/download. Cursor documents MDM rollout for Omnissa Workspace ONE, Microsoft Intune (Windows and Mac) and Kandji. If your network uses ZScaler, a proxy or a VPN that blocks HTTP/2, set HTTP Compatibility Mode to HTTP/1.1 under Cursor Settings → Network.

Three vendors are documented, so if yours is not among them you are packaging the standard download yourself. Budget for that in the rollout plan rather than meeting it on deployment day. The network side is a separate problem with its own guide: proxies that block HTTP/2 are the usual blocker, and the network configuration page has the allowlist and the streaming tests.

Before you pin a version in MDM, check one number: team usage analytics need client 1.5 or newer. An older pinned build will not report into the dashboard, which is an unpleasant surprise for whoever promised leadership an adoption chart. Pin forward, and give the fleet an update cadence you can actually hold to.