Firewalls for SMEs: what actually matters

A firewall in an SME determines more than just "allow" or "block". What actually matters comes down to four things: network segmentation that limits the damage when something goes wrong, a rule set that stays understandable instead of sprawling for years, a reliable update cadence, and monitoring that actually raises an alert on unusual events instead of just logging them. A firewall that's never touched again after installation only protects you on paper after a couple of years – the devices behind it have changed, the threat landscape has changed, only the rule set has stood still.

Why segmentation matters more than the firewall rule itself

Many businesses picture a firewall as a wall at the edge of the internet – everything inside is trusted, everything outside is a threat. In practice, most incidents don't come through the outer wall at all; they come from a single compromised device on the inside: an infected laptop working from home, an IoT device still on its factory password, an email attachment. Without internal segmentation, an incident like that can spread freely through the entire network. With segmentation – office, servers, cameras and guest Wi-Fi each in their own zone with defined rules between them – an incident stays contained to one area and can be dealt with before it takes down the whole business.

• Separate the server area and accounting systems from regular workstations
• Put cameras, printers and other connected devices in their own zone with no access to workstations
• Isolate the guest Wi-Fi strictly from the internal network
• Between zones, only allow the connections actually needed – not "everything to everything"

What belongs in a rule set you can still understand in two years?

Firewall rule sets grow over the years because a new rule gets added for every new application, while old rules are rarely removed again. After a while, nobody remembers what rule 47 was actually for, so out of caution it stays. The result is a rule set full of open ports that were granted years ago for a system that's long since been decommissioned. A rule set that stays maintainable needs structure: clear naming, a documented purpose for each rule, and a recurring point in time where someone actually checks which rules are still needed.

• Document each rule with its purpose and owner, not just its IP addresses
• Regularly check which permissions are still actively used – remove the ones that aren't
• Apply "as open as necessary, as closed as possible" instead of blanket permissions
• Log changes so it stays clear who changed what, and when

How often does a firewall and its rule set need updating?

Firmware and security updates for the firewall itself should be applied promptly once the vendor releases them – for critical vulnerabilities, the gap between disclosure and exploitation is often what counts. That can't be fully automated in a live environment, because updates should ideally be tested before going into production, but there should be a defined process for it rather than an ad-hoc decision after the fact. Just as important: the rule set itself needs a trigger for review, not just the firmware – new employees, new software or a move to new premises are all good opportunities to double-check existing permissions.

Is a single firewall at the internet edge enough?

For most SME sites, a well-configured firewall at the internet edge is the right starting point – not every business needs several redundant devices. What matters more than the number of devices is that the one firewall actually delivers what's described above: internal segmentation, a well-maintained rule set, timely updates and reviewed monitoring. A second device as failover only becomes relevant once an outage of the internet connection or the firewall itself would genuinely bring operations to a halt – something you can judge based on how dependent the business actually is on continuous reachability.

What's the point of monitoring if nobody reads the logs?

A firewall logs almost everything by default – the question is whether anyone actually reviews those logs. Without active monitoring, unusual patterns go unnoticed: repeated login attempts from unusual regions, a device suddenly sending large amounts of data outbound, or a connection to a known malicious address. For smaller businesses this doesn't have to mean a full security operations centre – what matters is that defined events actually trigger an alert instead of disappearing into a log file nobody opens.

• Unusual events (repeated failed logins, abnormal traffic) actively trigger an alert
• Clear ownership of who receives an alert and who acts on it
• A regular, brief look at the review rather than just collecting logs with nobody reading them

How should remote access for maintenance be handled?

Almost every firewall in an SME has at least one remote access path – for the company's own IT provider, for remote server maintenance, or for employees working from home. That path is a popular target precisely because it deliberately opens a way from outside to inside. A permanently open path with no additional protection is an unnecessary risk regardless of how trustworthy the provider is – credentials get stolen, the provider itself doesn't get compromised.

• Remote access for maintenance only via VPN with multi-factor authentication, never through individually opened ports
• Time-limited or on-demand access rather than a permanently open connection
• Log every remote maintenance session – who accessed what, and when

What does this mean for the support contract?

Before signing a contract, it's worth asking what's actually included: are updates applied proactively, or only on request? Is the rule set reviewed on a fixed schedule, or does it stay untouched until a problem shows up? Is there a committed response time for a security incident, or does "best effort" apply with no specific timeframe? Putting these points in writing prevents misunderstandings later about what was actually agreed. It's also worth asking for a short annual report: which updates were applied, which rules were removed, and whether any unusual events occurred. Without that transparency, a contract is hard to check against later, because there simply are no records to refer back to.