Network policy

Set on Network Policy in your console. It is evaluated at every sign-in, in every deployment mode.

Mode#

Start in watch. It gives you real data about who a rule would have stopped before it stops anyone, and it is what Safe Rollout is built on.

Rules#

How the signals combine#

In "Into one score", Low, Medium and High are worth 1, 2 and 4. With Tor on High, VPN on Medium and proxies on Low the three are worth 57, 29 and 14 points out of 100: a sign-in through a VPN passes the other two and scores 71; one through Tor fails both the Tor and VPN signals and scores 14.

Behaviour checks#

These compare a sign-in with what the same person has done before. Each has its own response, such as flagging the sign-in or asking for a second factor.

By default new country and impossible travel ask for a second factor rather than refusing. That is usually the right answer: the real user passes in ten seconds, and someone holding only a stolen password does not.

Decisions#

Every sign-in ends in one of three decisions, recorded with its reason on Sign-in Activity:

Changes to the policy are versioned, so you can see what the rule was at the time of a decision and not only what it is now.

Session binding#

A network policy that only runs at sign-in says nothing about a session that is copied to another machine afterwards. Session binding compares each request with where the session started.

In gateway and connector mode it is checked on every request before your application sees it. In SDK mode your application checks it, and needs its proxy trust set correctly.

Choose sign in again for people who move between networks during the day, such as a laptop going from office Wi-Fi to a phone's hotspot. Choose end the session for applications used from a fixed place.

Re-checks while a session is open#

Binding notices a session that moves. It cannot notice one that stays where it is while the rules change around it: you block a country at 10:00, or an address is added to a VPN list, and somebody already signed in from there carries on until their session expires.

So while the policy is enforcing, the address each open session is on is judged against it again every minute, whatever is chosen above. The choice above is about moving between networks the policy accepts, such as a phone going from Wi-Fi to mobile data; it does not switch the policy off for somebody who is already in. What happens next follows the same two lines the policy draws at sign-in:

This works in every deployment mode. Each one is written to Sign-in Activity, to the audit log, and to the session.terminated webhook.

It is cautious on purpose:

• a session that has not moved is judged on its address only. A session that moved is judged as an arrival: a new country, a new provider and impossible travel are asked about it, against the person's own history. The time zone check is the exception: only the sign-in page can read a browser's time zone, so it is asked again when the person next signs in;
• an address the lookups cannot place is left alone. Nobody loses access on missing information;
• in watch mode nothing is ended, because that is what watch mode means. What would have happened is put on the session log and the bell, so you can see it before switching to enforce;
• at most ten sessions are acted on for a tenant in any ten minutes, so a rule edited by mistake cannot sign a whole company out at once;
• for the second-factor band: a session that was opened with a second factor is left alone, a policy whose band lets people through is obeyed, and nobody is sent back twice in twelve hours.

What a refused person sees#

A page in your application's name that says what is wrong ("You are connected through a VPN"), what they can do about it, the address they are seen at, and a reference such as SI-55256.

The reference is the id of the record in Sign-in Activity. Type it into Account or reference there and that one line opens, with every check that was run. Somebody pressing Try again for a minute is one record, not sixty.

Blocked addresses#

Separate from the rules you write: an address is blocked automatically after repeated failed sign-ins. See Lockout policy. Blocks are listed on IP Blocks.

Which of the three stopped someone#

In order, when somebody is refused:

1. an automatic address block: temporary, expires by itself, shown on IP Blocks;
2. your network policy, only if it is in enforce mode;
3. your device policy.

Sign-in Activity shows which one, per event, with the reason. That includes a sign-in refused before the sign-in page loaded, and a session ended on a re-check.