Contractors and third-party access

External people who need one application, for a defined period, from a defined place, and who lose it the moment the engagement ends.

External access is where over-granting is most expensive and most common. The contractor needs one application; what they usually receive is the same access an employee has, because that group already existed and reusing it was quicker.

The shape that works here is narrow on purpose: a group that exists only for them, one access rule to one resource, and a device requirement that bounds where and on what they may connect from.

Setting it up

1
A group of their own
Create a group that exists only for this engagement: open People → Groups → Create group, type its name and choose Create group. Put nothing else in it. See Groups.
2
Invite them into that group
Open People → Members → Invite member, fill in Full name and Email address, and leave Role at User. Under Auto-assigned groups, pick the contractor group and nothing else, then choose Send Invitation. Taking that group off their record later ends the arrangement on every device they have, as long as group propagation stays on. See Add members.
3
Have them enrol by signing in
Ask the contractor to connect by signing in, never with an enrollment key. A device enrolled with a key has no owner and never expires. Blocking or removing the contractor would not touch it, and session expiry would not apply to it.
4
A group for what they work on
The access rule's destination is a group that holds only the machine they work on. Create it as you did the contractor group, under People → Groups → Create group. Then open that machine under Devices, add the group under Assigned groups and choose Save changes. If what they need is a network resource, skip this step: in the next step you create the access rule from the resource itself.
5
One access rule, one resource, one port
Source: the contractor group. Destination: the group from the previous step. You set both under Access → Access rules → Create access rule. For a single network resource, start the rule from the resource instead: on its network's page, choose Add Access rule in the resource's Access rules column, and the resource is the fixed destination.

Protocol and port: exactly what the application uses; a new rule starts at any protocol, which opens every port, so change it. Direction: One-way. Save it with Create access rule.
6
Bound where they may connect from
Attach a device requirement to that access rule. Open the rule again by selecting its row under Access → Access rules, and in its Device requirements section choose New requirement. Open each of the two checks below, set it and choose Save. Then choose Continue, name the requirement and choose Create Device requirement. Back in the rule, choose Save access rule: until you do, the rule does not use the requirement.

Country & Region, set to Allow with the countries they work from: a country you did not think of is refused rather than permitted, and so is a device whose location cannot be resolved. Operating System, with a minimum version for the platform they use and every other platform set to Block: a platform you leave at its default is allowed in any version.
7
Keep device session expiry on
A device enrolled by signing in has to sign in again when its session runs out, which bounds how long a machine keeps its access without the contractor proving who they are. It is on by default, for 24 hours, under Settings → Security → Expire device sessions and Session length. The length applies to the whole organization; on a device's own page you can only switch Session Expiration on or off, so leave it on for their machines. See Organization settings.
8
Check what they can reach
Once they have signed in, open their device under Devices. Assigned groups should show only All and the contractor group. The Accessible devices tab should list only what the access rule reaches: the destination devices, or for a resource, the routing devices of its network. Anything else there comes from another access rule that names one of the device's groups, All included. If the list is empty, check that the device passes the device requirement and is in the contractor group.

What each control actually bounds

Control	Bounds	Where
Contractor group	Who. Taking it off their record removes access from every device at once while group propagation is on	Groups
Access rule	What, on which protocol and ports	Access rules
Country & Region check	Which countries they may connect from. A device whose location cannot be resolved is refused	Device requirements
Operating System check	Which platforms, and how current. A platform not set to Block is allowed	Device requirements
Device session expiry	How long a device stays signed in before the contractor has to sign in again	Organization settings

When the engagement ends

Choose Remove from this organization on the contractor's member page. That deletes every device they enrolled by signing in, and their access tokens, in the same step, so nothing is left waiting to be revoked. If you need them out before you get to it, block them first: blocking refuses the dashboard and the API at once and expires their devices.

Then delete the access rule and the contractor group, or keep both for the next engagement. A group that an access rule still uses cannot be deleted, so the rule goes first. The full order is on Offboarding, and it applies to contractors exactly as it does to employees.

When this is the wrong shape

If the third party cannot run SXAccess at all - an external system that calls one of your webhooks, for instance - this arrangement does not apply. SXAccess only connects devices that run it; it does not make a service reachable from the public internet. Such a system needs a service you publish by other means, outside SXAccess.