How trust decisions are made
This page covers the mechanics behind a policy: when access is instant and when it waits, how addresses are looked up, which address is checked, how long answers are reused, and what happens when a check has no answer. You do not need any of it to use the Trust Engine. It is here for when you want to understand the timing or read the Activity trail closely.
Instant and waiting grants
Signing in never waits on a provider. When a user signs in, or their address changes, every Knoc that can be decided from what Knocknoc already holds is granted at once: a Knoc with no policy, one whose policy only checks country or known networks, and one whose provider-backed conditions are all set to Observe.
A Knoc that could Block or Challenge on a provider's answer waits only when that answer is not already in hand. Its tile reads Checking your connection, and it is granted or refused on the next page refresh without the user doing anything.
The wait is bounded. A lookup is given a few seconds, and a waiting Knoc is decided within about seven seconds of sign-in whether or not the provider has answered. A provider still silent then counts as failed for the rest of that session: under Allow access the Knoc is granted, under Apply the restrictions it is refused. So the longest a tile shows Checking your connection is about seven seconds plus one refresh.
If the server restarts while a Knoc is waiting, the next refresh picks it up and decides it, so access still arrives on its own.
Looking up an address before sign-in
Knocknoc starts looking an address up as soon as the sign-in page loads, so the answer is ready by the time a policy needs it. It does this only for a browser it already knows: one a user has completed a sign-in from in the last seven days (after any authenticator step, never on a password alone, and never in kiosk mode). A browser nobody has signed in from is still served; its first sign-in just does not get the head start.
Each user's known browsers are listed under Admin > Identities. Forget removes one, and its next sign-in is treated as new.
Which address is checked
The address the person is connecting from, never the addresses a Knoc opens. A policy asks where the connection comes from, so a Knoc that opens a fixed set of addresses is checked once against the connecting address and then opens all of them.
For example, a policy that allows your office range grants someone in the office and refuses someone outside it, whichever address the Knoc itself opens. Addresses a client discovers behind a CGNAT, and addresses a delegated or agentic grant asks for, are each checked in their own right.
Challenges across a session
One confirmation satisfies every policy the user's Knocs use, and covers every address that session touches. A sign-in itself counts as a confirmation, so someone who just signed in is not asked again inside the window. An API key never counts, because a stored key is not a person.
The every matching request setting is the exception: it asks each time and a sign-in does not stand in for it, so it stays strong even behind an identity provider that answers a re-prompt from an existing session. Use it where a confirmation must mean a fresh, deliberate action.
How long an answer is reused
A threat-intelligence answer is reused for one hour on the server that fetched it, so a second sign-in from the same address within that window costs no lookup. Within a single session an address is only ever looked up once. Clear cached answers on the Threat intelligence page drops every stored answer, so the next sign-in asks again.
If a provider cannot be reached, Knocknoc falls back to the last answer it stored for that address, up to seven days old, rather than guessing: a VPN exit stays a VPN exit, a clean address stays clean. The Activity row says the decision used a stored answer and how old it was. Stored answers live on each server and do not survive a restart.
When a check has no answer
A condition that reads a provider needs an answer before it can decide. The Activity feed names which of these applied:
- The provider reported nothing. Most addresses are unknown to a threat-intelligence source. That is an answer with nothing to act on, so the condition does nothing.
- The provider could not answer (a timeout or an error). Each policy's If a data source cannot answer setting decides: Allow access (the default) lets the connection through; Apply the restrictions applies each affected condition's response as if it had matched.
- Nothing asked the provider (no key, a plan that does not include it, or a private address no provider can look up). The condition does nothing.