Syncing users from JumpCloud into authentik: what the integration does
Some teams keep JumpCloud as the system of record for users and groups while authentik handles sign-in to their applications. For that model, authentik can pull users and groups from JumpCloud through either an LDAP source or a SCIM source, and the two methods differ in one decisive way: whether JumpCloud passwords are used to log in. An LDAP source also lets users authenticate against their JumpCloud password, while a SCIM source provisions directory data only, so users keep authenticating through authentik's own credentials or another upstream method. authentik documents both paths in its JumpCloud directory sync guide, and that choice is the main design decision in this integration.
The choice shapes almost everything that follows. With the LDAP source, JumpCloud becomes part of the login path, so an outage or policy change in JumpCloud affects sign-in to every application behind authentik, and password policy and lockout behavior are shared between the two systems. With the SCIM source, JumpCloud remains the directory for identity attributes and group membership, but credential handling stays with authentik, which keeps the sign-in dependency narrower and limits what a directory change can break. Teams should decide early which systems own password verification, MFA enrollment and account suspension, because each answer changes the source configuration and the support runbook.
Before choosing, confirm three things with your JumpCloud administrator and your own environment. First, confirm which JumpCloud data center holds your organization's data, because the LDAP endpoint and admin login URL differ by region and must match that location. Second, confirm which groups must reach authentik, since group scope drives the mappings and the authorization rules you will write. Third, confirm how suspended users should behave in authentik, because JumpCloud retains suspended users and bills them as normal users, so their removal from authentik is a process you must define rather than something the sync handles automatically.
What you need before connecting JumpCloud to authentik
Four areas need to be ready before any sync runs: the JumpCloud tenant, the authentik deployment, the network path between them, and the certificate trust that LDAP requires. Confirm each one with the owner of that system, because a gap in any of them usually shows up as a failed bind or an empty group list rather than a clear error.
JumpCloud admin access and plan
Someone needs administrator rights in the JumpCloud Admin Portal to create the LDAP or SCIM binding, assign users and groups to it, and generate the bind credentials. Confirm that your subscription includes the LDAP or user lifecycle features the chosen method depends on, since JumpCloud sells these as separate packages and as parts of bundles. Verify the exact feature names against current JumpCloud pricing and documentation before you commit to a method.
Correct regional data center and endpoint
JumpCloud runs separate United States, European Union and India regions, and each has its own LDAP and RADIUS endpoints. Your organization must use the admin login URL of the region that holds its data, so the LDAP host in authentik must match that region. Ask your JumpCloud administrator which region the tenant lives in before you copy any endpoint into a configuration.
Supported authentik version
Run a version listed as receiving security fixes in the authentik security policy, and check the release notes for the version you target before you connect a directory. The security policy and the releases page are the sources to check the current supported line against, because the list changes as new releases ship. Record the exact version so that later upgrades and troubleshooting start from a known baseline.
PostgreSQL and the worker container
authentik stores its configuration and data in PostgreSQL and needs the worker container running, because directory sync runs as a background task. Without a healthy worker, the source will appear configured but no users or groups will arrive. Confirm that PostgreSQL is sized and reachable from both containers, and remember that since the 2025.10 release PostgreSQL also carries caching, tasks and sessions.
Network path to the regional endpoint
The authentik server or worker must reach the JumpCloud LDAP endpoint for your region on the LDAP port your method uses. Check outbound rules on firewalls, proxies and cloud security groups from the authentik host, not from your workstation, because a test from a laptop proves little about the production path. Ask your network team to confirm the route before the first sync.
Certificate trust for LDAPS
An LDAP source that uses TLS must trust the certificate presented by the JumpCloud endpoint, and authentik runs in your environment, so the trust chain has to be available to the containers that make the connection. Confirm which CA chain JumpCloud presents for your region with JumpCloud documentation, then add it to authentik according to your deployment method. A certificate mismatch looks like a connection failure, so test it before you debug bind credentials.
LDAP source or SCIM source: which method fits your login model
The first decision is who should own the password. authentik supports two ways to bring JumpCloud users in, and they differ in where sign-in is checked. An LDAP source synchronizes users and groups and also lets people log in with their JumpCloud passwords, so authentik validates each password against JumpCloud at sign-in. A SCIM source provisions directory data only: users and groups arrive in authentik, but authentik keeps its own credentials and JumpCloud is not in the login path. The authentik JumpCloud guide describes both options, and the choice should be made before any sync is configured because it changes who resets passwords, where MFA is enforced and what happens during an outage.
The trade-offs fall into four areas. For password ownership, LDAP keeps one credential store, but authentik depends on JumpCloud to verify every login. SCIM means authentik holds its own credentials, so the team must define password policy, reset and recovery inside authentik. For MFA, check whether the factors your users already enroll in JumpCloud can be enforced in the authentik flow, or whether authentik's own second factors become the single control point. For offboarding, confirm how a user disabled or suspended in JumpCloud is reflected in authentik, and whether existing sessions and tokens are revoked on that event. For availability, LDAP sign-in fails when JumpCloud or its regional LDAP endpoint is unreachable, while SCIM sign-in continues during a JumpCloud outage for users whose local credentials exist, but new provisioning stops until the sync runs again.
Before choosing, answer these questions and confirm the answers in a test tenant: Which JumpCloud region holds your data, and therefore which LDAP endpoint and admin login URL apply? Who must be able to reset a password, and in which system? Is MFA required for every application or only some? How quickly must a leaver lose access, and does your team accept the sync interval? What is the plan for a JumpCloud outage? Your answers will also determine whether a JumpCloud license tier is needed for the directory features you rely on, which should be checked against JumpCloud pricing and the scope agreed with DeployOpen.
How to configure the JumpCloud sync step by step
This sequence connects JumpCloud to authentik in a defined order, so you finish with a source that imports directory data and a test login that proves the chosen method works. Each step closes with a check you can run before moving on.
Confirm the regional JumpCloud endpoints
The directory administrator confirms which JumpCloud data center holds your organization's data and uses that region's admin login URL for all configuration work. For an LDAP source, note the matching LDAP endpoint for that region, such as the EU endpoint pattern ldap.eu.jumpcloud.com if your data sits in the EU data center. JumpCloud requires the admin login URL of the region holding your data, so logging in to the wrong region is the first thing to rule out. Check: the admin portal loads under the expected regional URL, and the endpoint you recorded matches the region listed in JumpCloud's data center documentation. Confirm the exact endpoint in the authentik JumpCloud guide before you enter it.
Create the bind or SCIM credential in JumpCloud
A JumpCloud administrator creates the credential authentik will use to read directory data. For LDAP, this is a service account or bind credential with read access to the users and groups in scope. For SCIM, this is the provisioning credential that authentik's JumpCloud source expects. Keep the secret in your password manager, scope the account to the minimum read access the guide describes, and confirm the field names and permission settings in the authentik JumpCloud documentation because JumpCloud's interface changes over time. Check: the credential can authenticate from a test client, or the SCIM token returns user data when called from the approved network path.
Create the JumpCloud source in authentik
An authentik administrator creates a source for JumpCloud, choosing LDAP if users should sign in with JumpCloud passwords or SCIM if JumpCloud should only provide directory data and authentication stays elsewhere. Enter the regional endpoint and the credential from the previous step, and save the source without enabling broad sync yet. Confirm each field name against the authentik JumpCloud guide, since the labels are defined there. Check: the source saves without a validation error, and the connection test (where the guide provides one) reports success against the regional endpoint.
Set the user and group sync scope
The authentik administrator limits what gets imported by setting the base distinguished name or scope for users and groups, or the equivalent provisioning filters for SCIM. Narrow scope first, for example to one JumpCloud user group, because a broad first sync is harder to reverse than a narrow one. Decide now whether group membership should drive authentik access, since group mappings determine which applications and policies users inherit. Check: a dry review of the configured scope shows only the users and groups you intend to import, and no service accounts appear in the planned scope.
Run the initial sync
The administrator starts the first synchronization from the source page and watches the task status until it completes. Keep an eye on the authentik worker logs during this run, because background synchronization tasks run in the worker container. Note any users skipped for missing attributes or failed mappings. Check: the sync task reports completion without errors, and the number of imported users and groups matches what you expected from the JumpCloud admin portal for that scope.
Verify imported users, groups and a test login
Pick one test user in JumpCloud who belongs to the expected groups and confirm the account appears in authentik with those groups attached. Then run a test sign-in using the method you chose: a password login against the LDAP source if JumpCloud passwords are authoritative, or a login through your existing method if the SCIM path is used. Confirm the user lands in the intended application with the right permissions. Check: the test user's profile shows the expected groups, and the test login succeeds or fails exactly as the chosen method predicts. Record the results before expanding the scope.
Confirm the sync schedule and the rollback path
Before handing the source to operations, the administrator confirms how often synchronization runs and who can change or disable the source. Write down the steps to disable the source and remove imported users if the scope was wrong, and test that the disable action behaves as expected in a non-production instance if you have one. Confirm the schedule and any retention behavior in the authentik JumpCloud guide. Check: the schedule is documented, a named owner can change it, and the rollback steps have been walked through once.
How JumpCloud attributes map to authentik users and groups
This table compares each JumpCloud directory field with the authentik user attribute, group or source setting it feeds, and notes what sync does with it. Read it before choosing LDAP or SCIM, because the two paths expose different fields and handle passwords differently. Attribute names are marked for confirmation against the authentik JumpCloud guide and the JumpCloud LDAP schema before you rely on them.
| JumpCloud field | authentik target | Sync behavior and what to confirm |
|---|---|---|
| Username | User username and correlation key | Expected to be the stable key for matching existing users. Confirm the LDAP attribute name (for example uid) in the authentik JumpCloud guide and the JumpCloud LDAP schema. |
| Email address | User email attribute | Used for notifications and account linking. Confirm whether it is mapped on both the LDAP and SCIM paths, and whether duplicates are possible. |
| Given and family name | User name attributes | Mapped through the source property mappings. Confirm attribute names, since they differ between LDAP and SCIM payloads. |
| Account status (active or suspended) | User active flag | Suspended JumpCloud users are retained and billed as normal users, so confirm whether authentik deactivates them on sync or leaves them active. Test with one suspended account. |
| Group membership | authentik groups | Imported groups become the basis for application bindings and policy checks. Confirm group naming, nesting and whether membership is pulled or pushed on each sync. |
| Password hash or LDAP bind | Password validation source | On the LDAP path, users may sign in with JumpCloud passwords through the LDAP source. On the SCIM path, passwords stay in JumpCloud and authentik does not receive them. |
| Unique user ID | Source external identifier | Useful when a username changes. Confirm which attribute JumpCloud exposes for this on your chosen path before setting the correlation key. |
Choosing the JumpCloud region and deployment shape
JumpCloud runs data center regions in the United States, the European Union and India. Each region has its own LDAP, MFA LDAP and RADIUS endpoints, and an organization must use the admin login URL of the region that holds its data. If your tenant lives in the US region, every LDAP source you configure in authentik must point at the US endpoints, not those of another region. Confirm the region of your existing tenant before you copy any endpoint from a guide or a colleague's configuration.
- Endpoint match: Use the US LDAP host listed in JumpCloud's data center documentation for your tenant, and verify it with a test bind before you build the source.
- Admin login URL: Administrative tasks, including creating the service account used for binding, must happen in the admin login URL for that same region.
- Account location: Confirm in the JumpCloud admin console which region holds the organization before design work starts.
- Single region per source: Plan one LDAP source per directory tenant so a region mismatch does not silently sync an empty or wrong user set.
- Documentation check: Verify endpoints against JumpCloud's data center page at the time of the build, since endpoints are vendor-controlled.
Before you finalize the design, confirm the region with your JumpCloud administrator and record the endpoints in your architecture notes.
The EU data center uses endpoints such as ldap.eu.jumpcloud.com, and organizations must use the EU admin login URL when the tenant is hosted there. JumpCloud states that its EU data center runs on AWS in Frankfurt, Germany, but that data may still be processed outside the EU under its data processing agreement. It also states that only new customers can currently sign up for the EU data center. For an organization with residency obligations, this combination matters more than the endpoint itself.
- Processing scope: Ask JumpCloud in writing where data is processed, including support access and any sub-processors, and compare the answer with your residency policy.
- Sign-up status: Existing tenants in another region cannot simply move to the EU region on request, so confirm eligibility before assuming it is available.
- Contract terms: Review the data processing agreement with your legal and privacy team, not only the marketing description of the region.
- Sync data: Remember that the LDAP source copies user and group attributes into authentik, so authentik's own hosting location also falls within your residency analysis.
- Counsel review: Verify residency requirements with your own counsel and data protection officer before choosing this region.
Record the residency decision and the basis for it in your design documents so an auditor or assessor can trace it later.
JumpCloud also operates a data center region in India, with its own LDAP, MFA LDAP and RADIUS endpoints and its own admin login URL. The same rule applies as in the other regions: the region holding your directory data determines which endpoints authentik must reach and which admin console is used for administration. An organization that is subject to Indian data localization expectations or internal policy should treat the region as a governance decision and not a configuration detail.
- Endpoint confirmation: Obtain the India LDAP endpoint from JumpCloud's current data center documentation and test it from the authentik network segment.
- Network path: Confirm that outbound LDAP or LDAPS traffic from your authentik host is permitted to that endpoint through your firewall and proxy rules.
- Admin access: Ensure the administrators who manage the sync and service account know the India admin login URL and are not using a different region.
- Ask JumpCloud: Request written information on where data is stored and processed for an India tenant, and whether any processing occurs elsewhere.
- Local requirements: Confirm applicable local rules with your own legal advisers rather than relying on this page.
Keep the region, endpoints and the residency statement in the same record so that changes can be reviewed together.
The authentik Docker Compose guide positions Compose for test setups and small-scale production, and calls for a host with at least 2 CPU cores and 2 GB of RAM. A single Compose stack is a practical way to prove the JumpCloud LDAP source, group mapping and bind behavior before you commit to a production design. The trade-off is that Compose places the server, worker and PostgreSQL on one host, so recovery and scaling options are limited.
- Proof of concept: Use Compose to validate endpoints, the service account, the user and group filters and the sync schedule against a non-production JumpCloud tenant or a restricted test group.
- Host sizing: Start from the documented minimum of 2 CPU cores and 2 GB of RAM, and size higher for your user count after testing.
- Database backups: Set up PostgreSQL backups from day one, because the data the sync creates lives there.
- Migration path: Keep your configuration exportable so the source definitions can be recreated on a larger deployment.
- Production limits: Treat a single host as a learning or small-scale environment, and reassess before the directory becomes a sign-in dependency for many applications.
Before promoting a Compose build, confirm the residency decision and the backup and restore procedure with your operations team.
The authentik Kubernetes guide installs with Helm and states that the PostgreSQL bundled with the chart is for demonstration and test environments. For production, the guide recommends a separately managed PostgreSQL. This shifts the design toward a cluster with an external database, its own backup regime and clear ownership of connection capacity. Authentik's 2025.10 release notes also warn of roughly 50% more PostgreSQL connections after upgrading, so the database sizing and connection pooling plan must account for that.
- External database: Provision PostgreSQL outside the chart with tested backups and a restore procedure owned by your database team.
- Connection capacity: Size connections for the server and worker containers, and check the limits against the release notes for your target version.
- Replicas and workers: Plan separate server and worker containers so background sync tasks do not compete with sign-in traffic.
- Secrets handling: Store the JumpCloud service account bind password in your cluster secret mechanism, not in values files committed to source control.
- Network policy: Permit only the LDAP or LDAPS egress that the sync requires.
Before approving this shape, confirm the residency decision, the database ownership model and the recovery time your business requires.
Securing the JumpCloud connection
The JumpCloud connection carries directory data and, with an LDAP source, password checks into authentik, so its credentials and transport deserve the same care as the directory itself. The cards below cover the bind account, the SCIM token, the regional endpoint, the sync scope, logging and the license boundary that decides which controls you can use without a subscription.
Scope the bind account
An LDAP source needs a bind identity that can read the users and groups authentik imports. Create a dedicated JumpCloud service account for this purpose rather than reusing an administrator login. Grant it read access to the directory objects in scope and nothing more, and confirm in the JumpCloud admin console which permissions the account actually receives, since role names change between product packages. Record who owns the account and when its password was last rotated.
Rotate and store the credentials
Plan a rotation schedule for the bind password and the SCIM token before go-live, and rehearse the change in a test instance so a rotation does not cause a sync outage. Keep both secrets in your organization's secret store and inject them into authentik through its configuration rather than pasting them into the admin interface or into version-controlled files. Confirm with your security team who may view these values after they are created.
Protect the SCIM token
A SCIM source that provisions directory data gives its token the power to create and change users and groups in authentik, which makes it a high-trust secret. Restrict who can read or regenerate it in the authentik admin interface, limit the network paths that can reach the SCIM endpoint, and treat any exposure as a reason to rotate immediately. Review whether the token can reach groups that grant administrative roles in authentik.
Use the regional endpoint over TLS
JumpCloud serves each data center region on its own LDAP endpoint, and your organization must use the endpoint for the region that holds its data. Point authentik at that regional host, such as the EU endpoint when your tenant lives in the EU region, and keep TLS verification enabled with a certificate chain your authentik containers trust. Confirm the correct endpoint in JumpCloud's data center documentation before you configure the source, because a mismatched region can fail or expose traffic you did not plan for.
Filter the sync scope to required groups
Limit what authentik imports by setting the user and group filters to the JumpCloud groups that actually need application access, instead of importing the whole directory. Smaller scope reduces the personal data copied into authentik, shortens sync runs, and lowers the blast radius of a misconfigured source. Test the filter with a small group first, then review which accounts appeared and which were excluded before expanding it.
Plan logging and the license boundary
Review authentik's audit and log options before you commit to a design. Enhanced audit logging is listed among enterprise-only features on the pricing page, and most of the code is under the MIT license while the authentik/enterprise/ directory falls under a separate enterprise license. Ask whether your compliance team needs enhanced audit records for directory changes, then confirm with authentik which features are available on the edition you plan to run and whether a subscription is required.
Common JumpCloud sync failures and how to fix them
This table lists the failure points most likely to break a JumpCloud sync into authentik, with the likely cause, the check to run and the fix for each. Work through the rows in order, since a wrong regional endpoint or bind credential will mask every problem below it.
| Symptom | Likely cause | Check to run | Fix |
|---|---|---|---|
| Source cannot connect to JumpCloud | LDAP endpoint or admin login URL belongs to a different JumpCloud data center than the one holding your organization's data | Confirm your region in the JumpCloud admin portal and compare the LDAP host in the authentik source with the regional endpoint list | Change the server URL to the endpoint for your region, such as the EU LDAP host if your data is in the EU, then rerun the sync |
| Bind fails or sync stops working after a period of normal operation | Bind credential is wrong, was rotated, or belongs to a user or account that was disabled or lost its LDAP access | Test the bind user and password against the LDAP endpoint outside authentik, and check the account's status and LDAP binding in JumpCloud | Create or reissue a dedicated service account with the required LDAP access, update the bind DN and password in the source, and save before syncing |
| Groups are missing in authentik while users arrive | Sync scope or base DN filters exclude the JumpCloud user groups, or group membership was never assigned to the users | Compare the group entries in JumpCloud with the group-related settings and filters in the source, and check the sync logs for skipped objects | Widen the scope to include the group container, confirm the group membership attributes are mapped, then run a full sync |
| Same person appears twice in authentik | Correlation attribute changed, for example from username to email, so existing accounts no longer match and new ones are created | Compare the attribute used for matching on existing authentik users with the value now supplied by JumpCloud for the same person | Restore a stable matching attribute, merge or deactivate the duplicates in authentik, and document the chosen identifier before changing it again |
| Users who were suspended in JumpCloud still sign in or still appear | Suspended users are kept in the directory and billed as normal users, so they still exist as objects and the sync does not remove them unless configured to | Check the account status of the affected user in JumpCloud and whether the authentik source or its policies treat suspended accounts differently | Filter or deactivate suspended accounts in authentik through source or policy configuration, and confirm access is blocked at every application that uses authentik |
| Users can no longer sign in with their JumpCloud password after moving from LDAP to SCIM | SCIM provisioning carries directory data only, so no password is synced and authentik has no password hash to check against | Confirm which source type is active for the user and whether the user has a usable password in authentik | Plan a password path before cutover, such as a separate enrollment or reset flow, or keep the LDAP source for password validation if that design fits your requirements |
| Attributes or group-based access do not match what JumpCloud shows | Property mappings do not cover the attributes used for authorization, or the source maps a field that JumpCloud populates under a different name | Compare the attributes returned for a test user with the property mappings configured on the source | Update the mappings for the attributes your policies use, then resync the test user and confirm application access |
| Changes in JumpCloud are not reflected in authentik | Sync schedule has not run, the source is disabled, or a failed run is not visible because no one reviews the sync logs | Review the most recent sync run status and timestamps in authentik, and confirm the source is enabled | Re-enable the source, run a manual sync, and set up a routine review of sync results as part of operations |
Questions teams ask before syncing JumpCloud into authentik
What does it cost to sync JumpCloud into authentik?
The cost has three parts: the JumpCloud plan, the authentik edition and any subscription, and staff time for the integration. JumpCloud prices per user per month, and the plan you need depends on whether you want LDAP access, SSO, MFA or lifecycle management. JumpCloud lists Cloud LDAP and User Lifecycle Management as separate add-ons at $3 per user per month billed annually or $4 monthly each, while bundled packages start at $9 for Device Management, so confirm which combination your design needs. On the authentik side, the Open Source edition is free, but the LDAP and SCIM integrations for JumpCloud should be checked against the pricing page's list of enterprise-only features before you commit. Ask any partner for a quote built from a written scope that names each cost line.
Can an internal team set up the JumpCloud sync alone?
Often yes, if the team already runs LDAP or identity infrastructure and has a clear design. The work involves choosing between an LDAP source and a SCIM source, mapping attributes, testing group filters, and setting up a safe cutover. Teams without prior authentik or JumpCloud experience usually spend more time on the first sync and on troubleshooting edge cases such as duplicate usernames or group membership drift. Common ways to lower risk include:
- Reviewing the authentik JumpCloud documentation with a second engineer
- Running the sync in a test instance with a sample group
- Writing down the rollback steps before the production change
If these are not in place, a fixed-scope engagement can cover the design and testing.
How long does a JumpCloud sync setup take?
Duration depends mainly on directory size, how many attributes and groups you map, and how much testing your change process requires. A small directory with a few groups and default mappings is much simpler than an estate with nested groups, custom attributes and several connected applications. No duration figure is supplied for this work, so ask any provider to base the timeline on a written inventory of users, groups, attributes and target applications. Plan extra time for JumpCloud data center selection, since the region that holds your data determines which endpoints and admin login URL you must use.
What access and preparation does the sync need from our side?
The sync needs administrator access to both systems and a test group that represents real user variety. On the JumpCloud side, you need an admin account with permission to view users and groups, and, for LDAP, the ability to bind and read the directory. On the authentik side, you need an account that can create sources and property mappings. Before the first run, confirm your JumpCloud region, since each region has its own LDAP endpoint and admin login URL. Schedule a change window for the switch to production, and agree on who approves it and who can roll back.
Do users keep their JumpCloud passwords when authentik syncs?
It depends on the sync method. An LDAP source lets users sign in to authentik with their JumpCloud passwords, because authentik checks credentials against the directory. A SCIM source provisions directory data only, such as users and groups, so authentik does not receive passwords and users authenticate through another method you configure in authentik. Choose the method before you design user enrollment, MFA and recovery flows, because changing it later affects how users log in. Check the authentik documentation for how each source stores or validates credentials in your version.
How does JumpCloud billing treat suspended users?
JumpCloud bills accounts on the first day of each month for the previous month and states that suspended users are retained and billed as normal users. This means that disabling a user in JumpCloud does not reduce the bill, so offboarding in the directory must include removing or deleting accounts when the business no longer needs them. If your sync removes or deactivates users in authentik, that does not change JumpCloud billing. Confirm the current treatment with JumpCloud before you rely on it in your cost model, and review your lifecycle process so that inactive accounts are handled deliberately.
Should we choose the LDAP source or the SCIM source for JumpCloud?
Choose LDAP if users must sign in to authentik with JumpCloud passwords and you accept that the directory remains the credential store. Choose SCIM if JumpCloud should only supply users and groups, and authentication will run through a separate factor or method. Engineers should also check which group and attribute data each option brings in, and whether group-based access rules in authentik can use it. Test both options with a sample group before you commit, and record the decision with its reasons so that future changes to the directory or to authentik do not break sign-in.
Testing and operating the sync after go-live
Run the sync against a pilot group before you enable it for the whole directory. Pick a small set of users that covers each JumpCloud group your applications depend on, plus at least one suspended account. Export the same population from the JumpCloud Admin Portal users list as CSV or JSON (the files are named jcuserlist_yyyymmdd), then compare counts and attributes with what authentik created. Match user totals first, then group memberships, then the attributes your applications read, such as username, email and group names. Any gap usually points to a filter in the LDAP source's user or group search base, or to a group the sync does not reach. Confirm which scope your chosen method applies, since the LDAP and SCIM paths differ in what they carry, and record the export and the reconciliation result as your evidence for the change.
Test each sign-in method with a named account, not only with an administrator. For the LDAP path, log in to an application with a JumpCloud password, then confirm the user record in authentik shows the expected source. For the SCIM path, confirm that users sign in through their existing authentik credentials or through the identity provider you have chosen, because provisioning alone does not decide where passwords are checked. Also test offboarding: suspend a pilot user in JumpCloud, let the next sync run, and confirm that authentik's behavior matches your policy (deactivated, blocked from new sessions, or removed from groups). Ask JumpCloud to confirm how suspended users appear in each sync path, since the export and the sync may treat them differently.
After go-live, watch the worker container, which runs the background sync tasks, and the sync logs for failed or skipped objects. Review the worker's log output on a fixed schedule and alert on repeated sync failures, since a silent failure leaves offboarded users active. Schedule a fresh reconciliation against a new users list export after every authentik upgrade and after any change to JumpCloud groups or the LDAP source settings. Before you upgrade, check the sequential upgrade rule in authentik's upgrade documentation and confirm which versions you must pass through, because the sync configuration may need review at each step. Keep the pilot group and its test accounts in place so you can repeat the same checks after each change.
