Workspace security policies

Settings → Security policies sets rules that every member of the workspace must meet. You need the workspace update permission, which owners and admins have.

The four policies

Require two-factor authentication. Members without a second factor are stopped and sent to turn it on. The security page stays reachable so they can.

Require single sign-on. Members must have signed in through the workspace's SSO provider at least once. See the note in Single sign-on about what this does and does not enforce.

Session maximum age. Sessions older than the number of hours you set are ended on the next request, whatever the person's own settings say. Useful for shared machines and for meeting a policy that says eight hours.

IP allowlist. A list of addresses or ranges, IPv4 or IPv6, in plain or CIDR form:

203.0.113.0/24
198.51.100.7
2001:db8::/32

Only requests from those addresses may use the workspace. It applies to API keys too, which answer 403 from anywhere else.

You cannot lock yourself out

Saving is refused if the change would exclude you: requiring two-factor while your own account has none, requiring SSO while you are not linked, or saving an allowlist that does not include the address you are saving from. The page tells you which one applies and what to do first.

There is one case worth knowing: if the server cannot see a client address at all, because it is not behind a proxy that sets the usual headers, an allowlist cannot be saved from there. That is deliberate. An allowlist that cannot see who is asking would either block everyone or protect no one.

What members see

Somebody stopped by a policy gets a page that names the reason and offers the way out: a link to turn on two-factor, a note to sign in through SSO, or an explanation that the network is not allowed. Nothing is deleted and nothing is lost.

Auditing

Every policy change is written to the audit log with who changed it and when.