Device policy

Set on Device Policy in your console.

Mode#

What can be required#

Platforms#

Linux, Windows, macOS, Android and iOS. You choose which platforms are allowed at all, and each platform has its own switches and minimums: a minimum kernel and allowed distributions on Linux, a minimum build on Windows, a minimum version and security patch level on Android.

The score, and what is required#

Each requirement is given an importance on each platform:

Points average, and some facts are not for averaging: with every requirement at Medium, a rooted phone loses fourteen points and still signs in. Mark as Required what a device must never fail.

Two thresholds turn the score into a decision:

The middle band is off unless you set it. It is the kind answer to a laptop that is one update behind: the person still gets in, with a second factor.

The same number of points is a different bar on each platform, because each platform has a different number of requirements. With everything at Medium and a minimum of 67, Windows tolerates two failures, an iPhone one, and Linux none.

Operating system releases#

A device passes this requirement when its release is on the platform's list. Tick releases by hand or sync a vendor's list. A vendor's list says which releases are supported, not how patched they must be, so a release that a sync adds for the first time accepts any patch level.

Two overrides are applied last. Always allow passes the requirement for that release. Always block refuses the device outright, whatever it scores. On Linux only Ubuntu and the RHEL family are on the lists; name another distribution in an override, such as debian12, to accept it.

When the device cannot be read#

If posture cannot be read applies when the device could not be measured: the device service is unreachable, the reading is older than you allow, or the device is registered to another account. You choose Allow, Ask for MFA or Block.

A browser that reports nothing at all, or sends no device identity, is a different case. It has proved nothing, so it scores 0 and is refused in enforce mode like any failing device. Each such sign-in is recorded on the page.

The device agent#

The agent is a small program on your staff's machines. It reports the machine's security posture to your tenant.

What it reports#

• the operating system, its version and build;
• whether the disk is encrypted, the firewall is on and the screen locks;
• when it last checked in.

Install it#

Open Devices in your console and go to Install the agent. There are three ways, each already set up for your tenant.

The command carries a ticket that only your console can issue:

curl -fsSL "https://your-verisco-host/install/linux?ticket=<ticket>" | sudo bash

irm "https://your-verisco-host/install/windows?ticket=<ticket>" | iex

A rollout command is shown once, when you make it. After that the page lists it with how many machines it has installed, the address the last one came from and when it ends. Cancel stops it at once; machines it already installed keep working. The installer file holds your tenant's enrolment secret and does not expire, so keep it inside the tool that distributes it. Making or cancelling a rollout command and downloading the file need the Admin role, and each is written to your audit log.

Who still needs it#

Agent rollout, on the same page, lists everyone who signed in during the last 14 days, by the machine they last used:

The people with no agent come first, so the list is the work left to do. Run the policy in watch mode until it is empty, then switch to enforce: under enforce, somebody with no agent is refused at sign-in.

Users can also set up their own device from their page at /verisco/me, in gateway and connector mode.

Re-checks during a session#

A device that was compliant at 9:00 can have its firewall switched off at 9:05. With re-checks, each device's posture is read again every minute while its owner is signed in, and a device that falls below the bar is treated as it would be at sign-in. The session ends within about a minute of the change, and the reason is on Active Sessions and in the notification.

What ends a session during a re-check is what would refuse a sign-in: a score under the block line, a Required check that now fails, or a release marked Always block.

A score that falls into the middle band asks for what that band asks at sign-in: a second factor. The only way to ask somebody who is already in is to have them sign in again, so:

Nobody is sent to sign in again for their device twice in twelve hours, and a device that was already in the band when its owner signed in is not asked again.

A device that cannot be read changes nothing, whether the device service cannot be reached or its last reading is older than you allow. Nobody loses access on missing information: If posture cannot be read is a setting for the sign-in, and is applied at the next one. In watch mode nothing is ended and nobody is asked; what would have been done is recorded.

Each session the re-check ends, or sends to sign in again, is written to five places, so it can be found from wherever somebody starts looking:

Reading the results#

Rolling it out#

Do not go from off to enforce. Install the agent, switch to watch, read who would fail, fix or exempt them, then enforce. Safe Rollout tracks those steps for you.