Skip to main content

Blocked Grants

Knocknoc can refuse a grant when threat intelligence flags the connecting IP address. When that happens the grant is recorded as blocked rather than granted, and the user is told their access was refused. An administrator who trusts the connection can override the block and grant access anyway, with a required comment that is recorded in the audit log.

When a grant is blocked

A grant is blocked at grant time by one of two threat-intelligence checks:

  • GreyNoise — if the Knoc has Block grant if GreyNoise identifies the IP as malicious enabled, Knocknoc looks up the user's IP with GreyNoise at grant time. Configure the API key under Settings > Threat Intelligence. If the GreyNoise lookup itself fails (for example a transient API error), the check fails open: the grant is allowed and the failure is recorded, so a provider outage never locks your users out.
  • Static threat-intelligence list — if the user's IP is on the static threat-intelligence blocklist, the grant is blocked regardless of GreyNoise.

A block is distinct from a grant error. An error means the agent could not apply the grant to the device (a transient or device-side failure); a block means policy deliberately refused the connection.

What the user sees: the user is shown that their access was blocked by threat intelligence and advised to contact their administrator if they believe it is a mistake. The reason (GreyNoise vs the static list) is not exposed to the end user.

What the administrator sees

Blocked grants appear in the Knoc's activity / grant history, highlighted in red with a short status message describing why the connection was blocked. From there an admin can choose to override the block.

Overriding a blocked grant

Note: You need Admin to override a blocked grant.

  1. Log in to your Admin console: https://<your-server>/admin
  2. Open the Knoc where the grant was blocked.
  3. In the activity / grant history, find the blocked grant.
  4. Click Grant Anyway.
  5. In the Override blocked grant? dialog, enter a comment explaining why the override is justified. The comment is required — the confirm button stays disabled until you provide one.
  6. Confirm.

Knocknoc then re-processes the grant with the threat-intelligence checks bypassed. The resulting access is a normal grant: it is applied to the backend and follows the Knoc's usual grant duration and expiry. The override applies only to this specific grant; it does not change the Knoc's threat-intelligence settings or whitelist the IP for future logins.

How an overridden grant is shown

  • The original blocked grant is kept in the history and badged (overridden) so it is clear the block was deliberately bypassed.
  • A new grant, marked as an admin override, is created in the same activity entry and carries the access going forward.
  • The admin's name and the override comment are shown alongside the grant.

Audit implications

Every override writes a dedicated audit-log entry ("Admin overrode blocked grant"). The entry records:

  • the administrator who performed the override;
  • the required comment (the justification);
  • the user and the IP address the access was granted for;
  • the requesting IP the override was performed from;
  • the Knoc involved;
  • the user agent;
  • the time of the override.

In the audit log these entries appear under the Admin grants category (alongside manual grants), so you can filter for them directly. Because the original blocked record is retained and the override is separately audited, the full history is preserved: the block, who overrode it, when, and why.

Note: Overriding a block deliberately bypasses a threat-intelligence decision. Use it only when you trust the connection, and rely on the required comment to keep the decision accountable in the audit trail.

Back to top