By Yair Knijn · January 22, 2026

The IT manager whose block page looked like a malware warning, and trained users to ignore real ones

The DNS filtering went live on a Friday, and on paper it was clean: malware and phishing domains stopped resolving. What the IT manager left at the default was the block response. A filtered lookup just died on the wire, so users got ERR_CONNECTION_TIMED_OUT or a tab that spun forever — nothing connecting the dead page to a security decision anyone had made on purpose.

By the second week the service desk had a phrase for it. Anytime a site failed to load, the assumption was "the IT thing is acting up again" — so people retried, rebooted, or routed around it. The filter was doing exactly what it was bought to do. The lesson it taught was the damage.

A blank timeout is worse than no block at all

A timeout means nothing on its own. The user cannot separate a blocked phishing domain from dropped Wi-Fi, an expired certificate, or a backend that fell over, so all of it lands in one bin: noise. Anti-phishing research describes the pattern plainly — repeated exposure to warnings that all look identical produces fatigue, and fatigued people stop reading and swat warnings away on reflex.

The same work notes that employees already over-trust the controls their organization runs. A cryptic block feeds that: it never says "we just stopped something dangerous," and never shows the threat. You have spent budget making your people worse at the thing you bought the tool to fix.

The block page is the best security touchpoint you have

Every block lands on a person the second they reached for something risky — more attention than any training slide clicked through at 4:55 on a Friday. The page owes no lecture, just three answers: what happened, why, and what to do now. Drop one and the user writes their own ending, and that ending is "IT broke the internet again."

Clear reason, clear next step, clear way to ask for review

For the service-desk manager, the return is fewer tickets and sharper ones — it kills the "is the network down" calls and turns the rest into specific requests. The floor it must carry:

• The category that fired (phishing, malware, command-and-control) in plain words, not a rule ID.
• The requested domain, so the user can check it against what they clicked.
• A one-line reason plus a reference the helpdesk can search.
• A request-review link for false positives, pointed at a queue, not one inbox.

That review path earns its keep. Without it, a misclassified vendor tool becomes an angry escalation through a director. With it, the same event is a tracked exception you approve in minutes and hand to an auditor.

The page has to render when the console does not

The fastest way to torch trust is a block page that cannot load itself. If the response depends on reaching a cloud console over the same link that just got filtered, a captive portal or a VPN flap drops every block back into the generic timeout you were trying to escape. Serve it where enforcement happens. Render it from the endpoint agent, so a roaming laptop shows the same branded reason and review link it shows at a desk — exactly where the risky click tends to land.

Measure whether your warnings still land

You can test this instead of assuming it. Watch the ratio of "site is broken" tickets to "I got blocked, here is why" tickets; the two should flip once the page explains itself. And run a phishing simulation before and after — a click-through rate creeping up while coverage holds steady means you have trained warning-blindness into the staff.

ClearScreen renders a branded block page from the endpoint agent — category, requested domain, request-review link — so a block reads as a decision instead of an outage even when the console is unreachable. You set the wording and review queue per policy group. See how the block experience is built on the features page.