What is URL Filtering?
URL Filtering is a security measure that allows or blocks web traffic based on the requested URL, the domain or the category of the website, so that systems and users cannot connect to unsafe, unwanted or unauthorised web resources. The filter usually sits in a proxy, a next-generation firewall or a DNS service and compares every web request with policy, category lists and reputation data. In OT environments, URL Filtering prevents systems such as an engineering station, HMI or jump server from reaching malicious sites, unknown cloud services or an attacker’s command-and-control servers.
🧠 Why is URL Filtering important in OT?
OT systems should rarely have free access to the internet. Yet engineering stations, servers in the DMZ and maintenance laptops often need (temporary) web access for licences, documentation or updates. That is exactly where web traffic becomes an underestimated attack vector: malware arrives through a drive-by download, a phishing link steals credentials, or an infected system calls home to its operator over HTTPS.
| Risk without filtering | Possible consequence |
|---|---|
| Access to sites hosting malware | Drive-by download, infection of an engineering station |
| Visits to unauthorised cloud services | Data exfiltration, shadow IT |
| Unintended click on a phishing link | Stolen credentials or session tokens |
| Updates or tools from unsafe sources | Supply chain risk, installation of unverified software |
| Outbound traffic to command-and-control | Attacker keeps remote control over an infected system |
URL Filtering therefore works in two directions: it reduces the chance of infection through outbound requests, and it makes it harder for malware that is already inside to communicate.
🔧 How does URL Filtering work technically?
Every web request passes through roughly the same steps at the filter: the filter determines the destination, looks it up in a local or cloud-based database and then applies the policy (allow, block, warn or log). What the filter can actually see depends on where it sits and on encryption:
| Method | What is visible | Strength | Limitation |
|---|---|---|---|
| DNS filtering | Domain name only | Simple, works for every device | No control over path or file; bypassed with a hard-coded IP address or encrypted DNS |
| Explicit proxy | Full URL for HTTP; for HTTPS the hostname, and the path once decrypted | Central policy and logging | Clients must be configured to use the proxy |
| NGFW without decryption | Hostname via the SNI in the TLS handshake | No certificate management on clients | Path and content invisible |
| NGFW or proxy with TLS inspection | Full URL and content | Maximum control | Privacy, performance and certificate issues |
One important technical point: for HTTPS, a filter without TLS inspection only sees the hostname, not the
path. A rule on /download/firmware.exe will then not work. With Encrypted Client Hello (ECH)
the hostname in the handshake is encrypted as well, and filters that rely on the SNI lose visibility. DNS
filtering largely keeps working in that case, which is why organisations combine both layers.
🔍 What can you filter on?
| Filter type | Examples |
|---|---|
| Category | Social media, file sharing, hacking tools, webmail, newly registered domains |
| Reputation | Domains with a poor score in threat intelligence feeds |
| Domain name | example.com, vendor-support.com |
| Subdomain | updates.vendor.com, malicious.attacker.org |
| URL path (requires visibility of the full URL) | /download/firmware.exe, /scripts/backdoor.js |
| IP address geolocation | Destinations in countries where you have no suppliers or services |
| Time | Access only during an agreed maintenance window |
For office networks, category filtering is the starting point: everything is allowed except what is explicitly risky (a denylist). For OT the reverse is common: nothing is allowed except a short list of approved destinations (an allowlist, formerly called a whitelist).
🛠️ Where do you place URL Filtering in an OT network?
| Location | Application |
|---|---|
| Jump Server | Filter all outbound connections; often no internet at all |
| Engineering Station | Access only to approved vendor portals and documentation |
| Proxy in the DMZ | Central enforcement of filter rules and logging of every web request |
| Firewall or NGFW at the IT/OT boundary | URL Filtering as part of application inspection |
| Update or patch server | Only the vendors’ official update sources, supporting patch management |
In the Purdue Model, direct internet traffic does not belong on levels 0 to 2. Systems at those levels fetch updates and files through a server in the DMZ, and only that server gets (filtered) access to the outside world.
📐 Which standards call for URL Filtering?
- IEC 62443-3-3 - within the foundational requirement “Restricted Data Flow”, SR 5.2 calls for zone boundary protection, with the enhancement “deny by default, allow by exception”. SR 5.3 requires the capability to prevent general-purpose person-to-person messages, such as email and instant messaging, from being received from users or processes outside the control system; web access from control systems falls within the spirit of the same requirement.
- ISO 27002:2022 - control 8.23 “Web filtering” is new in the 2022 edition and asks organisations to manage access to external websites to reduce exposure to malicious content.
- CIS Controls v8 - safeguard 9.2 calls for DNS filtering and safeguard 9.3 for network-based URL filters based on category, reputation or block lists.
- NIST SP 800-82 - NIST’s guide to OT security recommends restricting internet access from OT networks as far as possible and routing it through controlled points.
For organisations that fall under the Dutch Cybersecurity Act (the Dutch transposition of NIS2, in force since 15 August 2026), URL Filtering is a concrete, demonstrable measure within the duty of care for network security.
✅ How do you introduce URL Filtering step by step?
- Inventory the need - record per OT system which external destinations are truly required: licence servers, vendor portals, update sources.
- Choose the location - central enforcement through a proxy in the DMZ is preferable to separate rules on every system.
- Start by monitoring - run the filter in log-only mode first and analyse a few weeks of traffic, so you do not break legitimate connections.
- Switch to default-deny - allow only the allowlist and block everything else, including categories such as newly registered domains.
- Link it to detection - forward blocks to your SIEM or SOC; a control network trying to reach an unknown domain is a strong signal.
- Manage and review - periodically check for wrongful blocks and missed threats (false positives and negatives) and remove destinations that are no longer needed, just as in firewall rule management.
Also make sure that temporary connections, such as a vendor laptop during remote maintenance, pass through the same filter.
🔐 How do you combine URL Filtering with other measures?
| Combined with | Result |
|---|---|
| DNS Monitoring | Domain name control plus control of URL path and category |
| Anomaly detection | Unusual web traffic from OT systems becomes visible |
| Security Awareness | Safe browsing supported by policy and training |
| Application Whitelisting / Application Control | Network control complemented by local application control |
| Email Filtering | Phishing links blocked both in the mail and at click time |
| Network Segmentation | Only systems that need web access ever reach the filter |
URL Filtering is one layer in defence in depth: DNS filtering, the URL filter, endpoint protection and monitoring each catch a different part of the attacks.
❓ Frequently asked questions
What is the difference between URL Filtering and DNS filtering?
DNS filtering blocks a destination at the moment the domain name is looked up, so it only sees the domain. URL Filtering inspects complete web requests and can also filter on path, file or category, provided the traffic is visible. The two complement each other and the CIS Controls list them as separate safeguards.
Does URL Filtering work with HTTPS traffic?
URL Filtering works with HTTPS traffic at hostname level, using the SNI in the TLS handshake or the CONNECT request sent to a proxy. Filtering on the full path requires TLS inspection, in which the proxy or firewall decrypts the traffic. In OT networks, TLS inspection is often limited to the proxy in the DMZ.
Is an allowlist or a denylist better for OT?
For OT systems an allowlist is better, because the number of legitimate web destinations is small and predictable. A denylist allows everything that is not (yet) known to be malicious. On office networks a category-based denylist is usually more practical.
Can URL Filtering stop malware?
URL Filtering stops malware that is spread through known malicious or suspicious sites, and it blocks connections to command-and-control servers. Malware that arrives on a USB stick or abuses an approved site gets past it. URL Filtering is therefore an addition to endpoint protection and segmentation, not a replacement.
Can URL Filtering be bypassed?
URL Filtering can be bypassed with a hard-coded IP address, encrypted DNS (DNS over HTTPS) or Encrypted Client Hello, because the filter can then no longer see the destination. In OT, therefore block all outbound traffic that does not pass through the proxy and allow only your own DNS servers. That keeps the filter the only path to the outside world.
Should PLCs and HMIs sit behind a URL filter?
PLCs and HMIs should have no internet access at all, so a URL filter is a safety net for them rather than a solution. Block outbound web traffic from those levels completely and let only servers in the DMZ reach the outside world through a filtered proxy. A blocked attempt from an HMI is a valuable signal for your SOC.
📌 In summary
URL Filtering protects OT systems against uncontrolled web traffic by checking every web request against an allowlist, category or reputation. With a central proxy in the DMZ, default-deny, additional DNS filtering and integration with your SIEM, it is a concrete implementation of IEC 62443-3-3 SR 5.2, ISO 27002 control 8.23 and CIS Controls safeguard 9.3.