Setting Up and Testing Sophos Firewall Application Control

Application Control on Sophos Firewall identifies applications independently of mere ports. This allows you to specifically allow, block, or log remote control tools, tunneling applications, streaming, cloud storage, messengers, or risky browser circumventions.

The practical benefit only arises when Application Control is active in the correct firewall rule, the application is truly recognised, and logs are evaluated. A saved Application Filter Policy alone does not block anything.

Quick Answer

Application Control is used in two steps:

1. Under Applications > Application filter, plan or create an Application Filter Policy.
2. In the appropriate firewall rule, select Identify and control applications (App control) under Other security features.

Afterwards, you must check with a real test client whether the traffic runs through this rule and whether the application is correctly recognised in the Log Viewer. For encrypted traffic, TLS Inspection can be crucial, as the firewall may see fewer details depending on the application.

When Application Control is Useful

Application Control is particularly useful when ports alone do not provide enough information. Many applications use HTTPS, changing targets, or cloud infrastructure. A pure port rule then only sees 443, but not whether it is an allowed business service, a remote control tool, or an unwanted cloud storage behind it.

Typical use cases:

• Blocking TeamViewer, AnyDesk, Tor, or proxy tools
• Restricting streaming or social media in certain networks
• Controlling cloud storage
• Limiting messengers or games in guest or school networks
• Activating application recognition for reporting and analysis
• Preparing traffic shaping for recognised applications

If it is not about recognition or blocking, but about prioritisation or bandwidth limitation, additionally configure Application Traffic Shaping on Sophos Firewall.

Prerequisites

Before configuration, these points should be checked:

• valid Web Protection subscription
• affected firewall rule is known
• Log firewall traffic is active for the test rule
• desired application or category is clearly defined
• test client and test target are defined
• for HTTPS applications, it is clear whether TLS Inspection should be used
• application signatures and pattern updates are working

Check the license status under Administration > Licensing. Application Control, including Synchronized Application Control, is part of the Web Protection subscription. Synchronized Application Control additionally requires Security Heartbeat and therefore a Network Protection subscription, a Sophos Central account, and a managed Sophos Endpoint with a trial or full license. Before deploying it in production, check not only the firewall bundle but also the status of the endpoints.

Planning Application Filters

A good Application Filter is not just a long blocklist. First, it should be clear what is to be achieved.

• Block risky remote control tools: Block specific applications or category
• Restrict guest Wi-Fi: Block unwanted categories, leave allowed basic services open
• Only log application: Initially use Allow with logging and reports
• Avoid false positives: Narrower application selection instead of broad category
• Prioritize business-critical application: Combine Application Control with Traffic Shaping

For productive networks, an observation mode is often useful: First activate Application Control, check logs and reports, then block specifically. This way, you can see which applications actually occur and whether a block would disrupt legitimate processes.

With broad criteria, also consider later maintenance. New applications are automatically included in Application Filter Policies and firewall rules through updates to the application signature database. If a rule blocks all high-risk applications, for example, a new high-risk signature may later be blocked without any additional manual policy change. This is intended, but it must be known in the change and review process.

Planning Rollout in Phases

Application Control should not be activated in one big step for all networks. A better approach is a small rollout with a clear test group, visible logging, and a defined decision on when observation becomes blocking.

A practical procedure:

• Inventory: Find out which applications actually occur. Application Filter with logging, without broad blocking yet
• Pilot: Check selected users or a test network. Block individual risky applications, closely monitor Rule ID and logs
• Production: Apply confirmed policy to target network. Activate filter in productive rule, document exceptions
• Operation: Monitor effects and side effects. Regularly check reports, Log Viewer, Central Reporting, or Syslog

Before going live, it should be clear which applications must remain allowed. These often include update services, remote support, collaboration tools, cloud storage, telephony, or industry-specific applications. If these dependencies only become visible after the block, Application Control quickly appears as a disruptive factor rather than a protective function.

For acceptance, a short decision list is worthwhile: Which application is blocked, which user group is affected, which exception is allowed, who is the technical owner, and when will the policy be reviewed? This documentation is more important than a perfect first filter.

Distinguishing Application Filter, Application Object, and Shaping

The terms are closely related but solve different tasks. This distinction saves a lot of troubleshooting:

• Application Filter: Defines which applications are allowed, blocked, or logged. Block remote control tools, restrict cloud storage, observation mode
• Application Object: Groups applications for an application-based SD-WAN route. It therefore determines which application traffic is routed together through specific gateways and does not replace an Application Filter.
• Application-based Traffic Shaping: Prioritizes or limits recognised applications. Prioritize Teams, limit streaming, throttle guest Wi-Fi
• Synchronized Application Control: Adds data from Sophos Endpoint systems via Security Heartbeat to application recognition. This is especially helpful for programs that the firewall would otherwise only identify generically or not at all.

For a block or allow policy, the Application Filter is the right starting point. An Application Object is only required for application-based SD-WAN routes; the procedure is covered in Setting Up a Sophos Firewall SD-WAN Route with Gateway Failover. Traffic Shaping is separate and is added when recognised applications need to be prioritised or limited.

Synchronized Application Control is not a replacement for clean firewall rules. It requires the subscriptions mentioned above, Sophos Central, Security Heartbeat, and suitable Sophos Endpoint coverage. Newly detected applications appear in separate categories such as SyncAppCtl discovered and should not be blocked blindly. Check first, then categorise, then add them to an Application Filter.

Detected applications automatically receive a status label: New for still-unknown applications, Mapped for applications automatically assigned to a category, and Customized for manually adjusted entries. Sophos supports Synchronized Application Control for up to 15,000 applications and stores only the last five occurrences per application and endpoint to save storage space. This limit matters especially when you need to forensically trace how often an application occurred on an endpoint.

After a migration to SFOS 21.0 or later, automatic cleanup is also enabled for active Synchronized Application Control, with a default retention period of twelve months. Individually added applications are also removed from Application Filter Policies during cleanup. If historical data or manually maintained filters are required, review this retention period deliberately.

Safely processing detected applications

When using it for the first time, Synchronized Application Control must be enabled in Sophos Central. Then open Applications > Synchronized Application Control, search by name, path, category, or endpoint, and expand the entry to review the detected occurrences.

For an unknown entry from SyncAppCtl discovered, select Customize under Manage > More options. Assign a meaningful name and the appropriate business category. Acknowledge marks a reviewed entry as processed without changing it, Hide only removes it from the current view, and Show makes it visible again.

Delete is not merely a cleanup action: It also removes the application from Application Filter Policies. If an endpoint detects it again later, it reappears in the list. Before deleting, therefore check which filters use the application; afterwards, retest the policy, the expected Firewall Rule ID, and a real traffic flow.

For the specific use case of generative AI, Detect and Control Generative AI with Sophos Firewall shows how Application Filters, endpoint telemetry, pilot operation and reporting work together.

Creating Application Filters

Menu path:

Applications > Application filter

On older SFOS versions, the path may still appear as Protect > Applications > Application filter.

Procedure:

1. Open Add.
2. Assign a descriptive name, for example, Block_Remote_Control_Tools.
3. Choose an existing policy as a template, for example an allow-all policy as the starting point for targeted block rules.
4. Save the policy.
5. Open the policy again and add a rule inside the filter.
6. Select application, category, risk, Characteristics, Technology, Classification, or Smart Filter.
7. Set the action, for example Deny or Allow.
8. Set a schedule if the rule should only apply at certain times.
9. Save the rule and then save the policy.

Set up Sophos Firewall schedules for rules and policies explains how to create the schedule and validate it against firewall time, rule order, and fallback rules.

Be cautious with categories. A broad category can affect more applications than expected. For initial tests, individual applications or clearly defined groups are often better than a large collective block.

When adding a rule, there are two typical ways to work. Select All with filters is suitable when an entire group is meant, for example Category File Transfer, Characteristics Transfer files, and Technology Browser Based. Select Individual Application is better when only individual applications such as AnyDesk, TeamViewer, or a specific cloud service should be affected. The Smart Filter searches the name and description of an application; it does not replace a technical review of the result list.

The Classification filter only applies to cloud applications. If a cloud app is reclassified later, Sophos Firewall also updates rules based on that Classification. Such rules are useful, but more dynamic than a fixed list of individual applications.

Example: Blocking Browser-Based File Transfers

A useful first example is blocking browser-based file transfers in a guest or client network. This does not block the entire File Transfer category indiscriminately; it narrows the selection to browser-based file transfers.

Configuration in the Application Filter:

1. Open Applications > Application filter.
2. Create a policy, for example Block_File_Transfer.
3. Choose a suitable allow policy as the template.
4. Save the policy and open it again.
5. Open Add for a new filter rule.
6. Use Select All and narrow the selection with Category: File Transfer, Characteristics: Transfer files and Technology: Browser Based.
7. Set Action to Deny.
8. Set Schedule to All the time unless time-based control is required.
9. Save the filter rule and then save the policy.

This example is deliberately narrower than a blanket block of all file-transfer applications. Otherwise many organisations would also affect legitimate cloud, update, backup or collaboration services. Before production use, test the filter in Log Viewer with real clients.

Activating in Firewall Rule

Application Control only takes effect when the filter is selected in a firewall rule.

Menu path:

Rules and policies > Firewall rules

Procedure:

1. Open the firewall rule through which the affected traffic actually runs.
2. Open the Other security features section.
3. Select the Application Filter under Identify and control applications (App control).
4. Activate Log firewall traffic, at least for testing and acceptance.
5. Save the rule.
6. Test with a defined client.

The order of rules is crucial. If the traffic is already processed by a more general rule above, it does not reach the rule with Application Control. Then the configuration in WebAdmin looks correct but has no effect.

If a new LAN-WAN rule is created, NAT must be considered separately. Sophos examples often use Create linked NAT rule with MASQ for simple Internet access. For existing production rules, however, do not create new NAT rules casually; check which SNAT/MASQ rule already applies to this traffic.

For user- or group-based Application Control policies, the firewall rule must really match the user context. Match known users and working authentication are just as important as the Application Filter itself. Without user context, the policy only applies to network, zone, and service criteria.

For new rules, also deliberately choose between IPv4 and IPv6. Application Control is activated in the respective firewall rule. If a client takes a different path over IPv6 than over IPv4, the test may look clean even though part of the traffic bypasses the expected rule.

The basics of Source, Destination, Services, Security Features, and rule order are covered in Understanding and Securely Configuring Sophos Firewall Rules.

Deliberately Check Rule Matching

Before saving, the rule should be read like a test case:

• Source zone and Source network: The test client must really come through this zone and this network
• Destination zone and Destination network: Broad destinations can work, but are harder to trace
• Services: TCP 80/443 is often relevant for web traffic; QUIC runs over UDP 443
• Web policy, IPS, and TLS Inspection: Several security features can affect the same flow
• Log firewall traffic: Without logging, the effect is hard to prove in Log Viewer

When Application Control is newly introduced, the first rule should preferably be somewhat narrower and easy to measure. A huge LAN-to-WAN rule with many exceptions is much more cumbersome for acceptance.

TLS Inspection and Recognition

Application Control can recognise signature-based applications even without full TLS Inspection. However, the DPI engine only recognises URL-based Micro Apps, such as Dropbox or Gmail file transfers, in encrypted traffic from the decrypted URL. A matching SSL/TLS inspection rule must actually decrypt the traffic for this to work.

If an application is not recognised as expected over HTTPS, you should check:

• Is the traffic running through the correct firewall rule?
• Is Application Control active in this rule?
• Is the application generally recognised by Sophos?
• Is TLS Inspection necessary and justifiable for this traffic?
• Does the client use QUIC or HTTP/3? QUIC cannot be scanned and bypasses Web Filtering; for controlled web traffic, check Block QUIC protocol in the matching firewall rule.
• Do Web Policy, IPS, or DNS Protection also apply?

TLS Inspection should be introduced gradually and with exceptions. The appropriate procedure is detailed in Properly Introducing Sophos Firewall TLS Inspection. For QUIC and HTTP/3, see Properly Blocking QUIC and HTTP/3 on Sophos Firewall.

The difference is especially visible with cloud applications: basic byte and usage data mainly require enabled firewall logging. More precise upload, download, and file type information is only reliably visible when HTTPS is decrypted. Some applications transfer files through their own mechanisms; detail fields can then remain empty or incomplete even though traffic exists.

For cloud app reporting, a three-part approach is therefore recommended: enable Log firewall traffic for basic byte counts, decrypt HTTPS where upload and download counters and file types are required, and use a Web Policy other than None for greater accuracy. The Web Policy is an additional Sophos recommendation; HTTPS decryption is the strict requirement for these file details.

Testing Effectiveness

After activation, do not just wait for user feedback. A clean test saves a lot of time.

Practical procedure:

1. Define test client and source IP.
2. Intentionally start the application or call the target.
3. Filter in the Log viewer by source IP, destination, service, and application.
4. Check which Firewall Rule ID was hit.
5. Check if Application Control recognises the application.
6. Note Application ID, category, action, and Application Filter.
7. In case of a block, check if the block is technically desired.
8. For unclear recognition, supplement with Packet Capture, Service Logs, and, for central logging, the Syslog fields.

The log type depends on the action: A blocked Application Filter match appears as Content Filtering > Application > Denied. Allowed traffic that is only detected instead appears in the firewall log as Firewall > Firewall Rule > Allowed. For acceptance, Firewall Rule ID, user, application, category, risk, action, source, and destination are especially relevant.

For Syslog or SIEM analysis, the output format must also be taken into account. In the current Central Reporting Format, important fields are named fw_rule_id, app_filter_policy_id, app_name, app_category, app_risk, app_resolved_by, qualifier, and status. The Device Standard Format (Legacy) instead uses fields including application_filter_policy, application_name, application_category, application_risk, and appresolvedby. Do not mix these two sets of names in the SIEM. The respective detection field indicates whether a signature, proxy or Micro App detection, or Synchronized Application Control (EAC) was involved.

Application Filter and application detection by the DPI engine log technical details in ips.log. Log assignment is covered in Sophos Firewall Troubleshooting: Services and Logs. For differentiation with Log Viewer and Packet Capture, see Testing Sophos Firewall Rules with Log Viewer, Policy Test, and Packet Capture.

Moving from Observation to Blocking

The change from pure detection to blocking should be deliberate. In many environments, it is better to use Application Control first as an observation and reporting tool. Afterwards, only block applications whose risk, user base, and business dependency are understood.

Before blocking, check:

• Which users, networks, or devices actually use the application?
• Which firewall rule and Rule ID appear in Log Viewer?
• Is the application reliably detected or only as a generic category?
• Is there legitimate business use, support activity, or vendor tooling?
• Should the application be blocked everywhere or only in guest, school, client, or server networks?
• Who approves an exception and when is it reviewed again?

A clean practical flow is: collect log data first, then block a single application or small group, then validate with a test client and Log Viewer. If a block is too broad, do not disable the entire Application Filter. Adjust the affected application, category, or rule position specifically.

When Application Control Does Not Take Effect

When problems occur, do not immediately disable the entire filter. First check where the process breaks.

• No log entry for the test connection: Logging is missing or traffic does not reach the firewall rule. Check Rule ID, source zone, and Packet Capture
• Log Viewer shows a different Rule ID: A more general rule is placed above it. Correct rule order and match criteria
• Application remains unknown or generic: Recognition is insufficient without more context. Check TLS Inspection, QUIC, and application signatures
• Block affects too many services: Category or Smart Filter is too broad. Use individual applications or smaller groups
• After a pattern update, more is suddenly blocked: A broad rule based on Risk, Category, or Classification matches new signatures. Check rule criteria and the change process.
• Cloud app details are missing: Upload and download counters and file types require HTTPS decryption. A Web Policy other than None additionally improves accuracy and level of detail. Check cloud app reporting, TLS status, and Web Policy separately.
• Block only works for some clients: Different rule, zone, user group, or browser path. Compare test client, user, and network path
• IPv6 behaves differently from IPv4: Separate IPv6 rule, different DNS path, or different browser path is possible. Test both protocols deliberately or account for IPv6 cleanly in the rule set.

The most important check is the Rule ID. If the expected rule is not matched, the Application Control policy is almost never the actual cause.

Properly Handling False Positives

If Application Control blocks legitimate traffic, do not immediately deactivate the entire filter.

Sensible sequence:

1. Document the affected application and log entry.
2. Check which firewall rule and which Application Filter are involved.
3. Check application, category, and action in the filter.
4. Check if the application is recognised differently by TLS Inspection.
5. Set exception as narrowly as possible: application, source network, user group, or target.
6. Document owner and review date for the exception.

An exception for Any or a broad category often quickly resolves the current case but weakens control permanently. A small, understandable exception with a clear justification is better.

Common Mistakes

• Application Filter created but not selected in rule: No effect on traffic. Activate filter in the actual firewall rule
• Traffic runs through another rule: Filter is never reached. Check Rule ID in Log Viewer
• Too broad category blocked: Legitimate cloud or business services affected. Use individual applications or narrower groups
• Dynamic filters misunderstood: Risk, Category, or Classification can produce new matches through signature and cloud app updates. Review regularly.
• Overestimated HTTPS recognition: Application not reliably recognised. Check TLS Inspection and QUIC behaviour
• Logging missing: Effect remains invisible. Activate rule logging for testing and operation
• Exception too broad: Protective function is practically nullified. Set exception narrowly and with review date

Operational Check

Application Control should be regularly checked. Applications change, cloud services use new endpoints, users use new tools, and signatures are updated.

Documentation should include:

• Purpose of the Application Filter
• Affected firewall rules
• Blocked or allowed applications
• Known exceptions
• Technical owner
• Review date
• Last relevant change

If Application Control is used for critical business applications, school networks, or compliance requirements, Central Reporting, Syslog, or SIEM should also be checked. For central evaluation, see Activating Central Firewall Reporting or Setting Up Sophos Firewall Syslog and SIEM.

Checklist

• License status checked.
• Affected firewall rule clearly identified.
• Application Filter created with a clear purpose.
• Template, dynamic filters, and rule criteria documented.
• Filter selected in the correct firewall rule.
• Rule logging active.
• Test client and test application defined.
• Log Viewer checked for Rule ID and Application Control.
• Real usage, owner, and exception rule clarified before blocking.
• IPv4 and IPv6 path checked if both are active in the network.
• TLS Inspection and QUIC evaluated if HTTPS recognition is unclear.
• Cloud app reporting checked with HTTPS decryption and Web Policy if needed.
• Exceptions narrowly documented.
• Review date set.

Frequently Asked Questions