Read the figure that matches how you will configure it, not the one on the front of the data sheet.

Manufacturers publish several throughput figures. The largest is plain firewall throughput with large packets and minimal rules - a number that describes the silicon rather than the deployment. Below it come figures for intrusion prevention enabled, for full threat inspection, and for inspection with TLS decryption, and each step down is substantial. Decryption in particular is expensive, and most traffic is now encrypted.

So an appliance quoted at 20 Gb of firewall throughput might manage 3 Gb with full inspection and rather less with decryption. If the intention is to inspect everything, that last figure is the specification.

Session counts matter independently. Concurrent sessions and new sessions per second limit how many conversations the device can hold and how fast it can establish them - and heavy web use creates a great many short sessions.

Size for three years' growth against the realistic figure.

At the boundaries that matter, and consistently - the common failure is inspecting the internet edge thoroughly while everything internal passes unexamined.

The internet boundary is the obvious place and the one everyone covers. But most incidents involve movement inside the network after an initial foothold, and internal traffic frequently passes no inspection at all - particularly where a Layer 3 switch routes between VLANs internally, which bypasses the firewall entirely.

So decide deliberately which internal boundaries deserve inspection: between user networks and servers, around operational technology, in front of anything holding sensitive data.

The other consistency question is remote users and cloud services. Traffic that once passed the office firewall may now go directly from a laptop to a cloud application, and if the policy exists only on the appliance at the office, that traffic is unprotected.

Mapping where traffic actually flows before buying an appliance is more valuable than the specification comparison.

Decrypting, examining and re-encrypting traffic - which reveals what inspection would otherwise miss, at a real cost in performance, complexity and trust.

Most traffic is encrypted, so an appliance without decryption sees only metadata: addresses, names and certificate details. Threats delivered over an encrypted session pass unexamined.

Decryption means the appliance terminates the session, inspects the content, and re-encrypts to the destination using a certificate the organisation's devices trust. It works, and it is the only way to inspect content at the network.

The costs are significant. Throughput falls sharply. Every device must trust the inspection certificate, which is straightforward on managed devices and awkward otherwise. Certificate pinning in some applications breaks entirely and needs exclusions. And there are privacy and legal considerations that vary by jurisdiction and must be addressed in policy and staff notification.

Most organisations decrypt selectively - inspecting general web traffic while excluding banking, health and similar categories.

Consolidated for most organisations, separated where scale or specialisation justifies it.

One appliance doing firewalling, inspection, filtering and VPN means one console, one policy, one support relationship, one set of updates and correlated logging - all of which matter more than they sound when a small team runs everything.

Separating functions makes sense at scale, where a dedicated device performs one job far faster than a consolidated one; where a specialist product is materially better than the consolidated equivalent; or where an architecture deliberately avoids a single point of both failure and compromise.

The honest assessment for most organisations is that a well-configured consolidated appliance outperforms a collection of specialist devices that nobody has time to tune. Capability that is not configured provides nothing.

What consolidation should not mean is a single device with no failover. High availability is a separate question and should be answered yes wherever the boundary is critical.

Essential - the appliance without current signatures and feeds is a stateful firewall and little more.

Intrusion prevention signatures, antivirus definitions, web categorisation, application identification and reputation feeds are all updated continuously and all delivered by subscription. When one lapses, the corresponding function either stops or continues with stale data, which can be worse because it looks as though it is working.

Budget for them as a recurring cost from the outset, and note that they typically cost a meaningful fraction of the hardware price every year.

Watch the renewal dates. An appliance whose subscription lapsed quietly is a common finding, and the device usually keeps passing traffic without complaint.

Also check what each bundle includes. Vendors package differently, and a lower tier may omit exactly the function that justified the purchase - sandboxing and advanced malware analysis are frequently separate.

Yes in nearly every implementation - same model, same software, same licensing - and the pair should be tested rather than assumed.

A high-availability pair synchronises configuration and session state so that failover does not drop established connections. That synchronisation requires matched hardware and software; mismatched versions usually refuse to form a cluster.

Both units generally need their own licences and subscriptions, though several vendors discount the secondary. Confirm this at purchase, because discovering it later means an unbudgeted cost or a standby that cannot inspect anything.

Active-passive is the usual arrangement and the simplest. Active-active gives more capacity but complicates state and asymmetric routing, and is worth it only when capacity genuinely demands it.

Test failover before go-live and periodically afterwards, including the case where the primary is powered off abruptly rather than shut down gracefully. Untested clusters have a poor record.

Somebody must, and deciding who before buying is what makes it a control rather than an expense.

Every appliance produces alerts, and alert volume is high by default. Without a person or a service reviewing them, tuning the noise down and acting on what remains, the appliance blocks what it blocks automatically and everything else is written to a disk nobody opens.

The practical options are a member of staff with the time and the training, a managed security service, or forwarding to a central log platform where correlation and alerting are handled.

Whichever is chosen, tune first. An untuned intrusion prevention system generates so many low-value alerts that genuine ones are lost, and the usual outcome is that everyone stops looking within a month.

Retention also matters. Investigating an incident usually means looking back weeks or months, and appliance-local storage rarely holds more than days. Central log collection is what makes the appliance useful after the fact.