“What router should I get?”

by

Every IT professional has been asked this question at least once in their life. While many of us have rank and file preferences we’ll happily share, in my opinion this is one of those sneaky questions that seldom warrants a direct answer. Let’s dig-in.

Use-Case and Environment

All routers provide the same rudimentary and universally-applicable core functions. Despite this, they represent an extremely diverse product category encompassing a myriad of sizes, features, and qualities, all lending themselves to vastly different use-cases and environments.

For instance, a large campus servicing thousands of users is going to require substantially more powerful (and more expensive) routing hardware than a single user residing in a small studio apartment. While some hardware vendors might be able to meet both ends of this spectrum in their product line-up, it is impossible for a single product to simultaneously fit all unique combinations of power and budget requirements.

Even if we eliminate the idea of scale and assume that this question is posed within the context of a home network, there are still countless other considerations that need to be taken into account. Most home “routers” are multi-function devices that also serve as switches, wireless access points, modems, and firewalls. While some homes can have all of their networking requirements met with a single multi-function device, others might require more. A large house may require a mesh solution to deliver ample Wi-Fi coverage. Some users may require cabling to be professionally installed in-order to facilitate low-latency, low-jitter network connectivity. Others yet may have an ADU or other structure on their property requiring buried fiber or point-to-point Wi-Fi.

As a result of these factors, the question “what router should I get” can never be directly answered; each scenario involves uncovering a unique set of user requirements, then satisfying them with a unique set of hardware and products. There are no one-size-fits-all solutions.

Unfortunately, use-case and environment aren’t all that we need to consider when providing product recommendations.

Risk Profile

The Internet is a dangerous place. Since routers generally serve as a gateway to the Internet, it is important to understand a user or organization’s risk profile before pelting them with product recommendations. While most people face no real threat from the Internet and are free to remain blissfully unaware of the dangers presented, in many contexts the answer to “what router should I get” fundamentally changes depending on who you are, what you do, what information you possess, where you live/work, and a myriad of other factors.

In the most extreme circumstances, providing risk-sensitive users with inappropriate off-the-shelf product recommendations will compromise the national security of nations actively engaged in war, or result in servicemembers being court-martialed and demoted during peacetime. While we’ll get into more detail later-on, in-summary, even if use-case and environment may be a good match, a product may be totally inappropriate to use depending on risk profile. Thus, it is crucial to understand security requirements before dispensing product advice.

Professional Consult Required

So far we’ve discussed why the question “what router should I get” lacks necessary nuance and context. While this information is crucial when providing product recommendations, the biggest problem I personally have with this question involves the informal and inappropriate contexts where it is typically raised.

The process of fleshing-out all of the aforementioned details concerning use-case, environment, and risk-sensitivity belongs squarely within the realm of professional (paid) consultation. It would be totally ludicrous to expect a lawyer to provide free legal advice, or for an engineer or architect to stamp somebody’s hand-drawn ADU plans. Yet, until the end of time, IT professionals will continue being asked for router recommendations in the break room, during family gatherings, and through random DMs… and alas, they’ll almost always provide an answer.

… But when it comes to free advice, the knife cuts both ways; you shouldn’t expect IT professionals to work for free, but when you do squeeze advice out of one, you’ll probably get what you pay for… in the form of an affiliate link, or maybe a long-winded sales pitch for an overpriced enterprise solution from an eager MSP representative fishing for their commission check.

Which leads into my final problem with this question…

IT Professionals are Biased

Even if you take the prudent step of paying for professional advice from somebody who isn’t being paid a commission to peddle hardware from a specific vendor, you’ll discover that IT professionals are, knowingly or not, guided by their own experiences, preferences and biases.

If somebody has principally deployed TP-Link or ASUS routers for home users, their recommendations will be shaped by those experiences. The same goes for professionals working for MSPs who adhere to specific standardized offerings from the likes of Ubiquiti, Fortinet, SonicWall, Palo Alto, or other router vendors; preferences are the result of subjective experiences with vendors and their products. Nobody is immune to tribalism no matter how much we might try to convince ourselves that we are capable of making objective and unbiased suggestions.

For instance, I personally like SonicWall… but if I take a step back, it is easy to understand why; they are by-far the vendor I am the most familiar with. In every single IT-related position I’ve ever held, I’ve installed and administered SonicWall equipment. I have an ancient NSA sitting in a box somewhere that used to run my homelab. I’ve lived and breathed SonicWall, so that when you ask me, “what router should I get”, the lizard in the back of my brain is just going to blurt-out what it has been programmed to understand.

This deep-rooted familiarity becomes further entrenched when presented with unfamiliar products from other vendors. I’ve frequently struggled to accomplish tasks using other vendors’ products which I might otherwise consider “easy” to accomplish using SonicWall equipment. On many occasions this has given me a bad first impression of other vendors despite the fact that the “easy” SonicWall task might have required a lot of repetition and continued exposure on my part to master.

In-truth, there are a lot of things SonicWall is bad at. For instance (and if recollection serves me well) the CLI implementation is trash. There are also a lot of infuriating quirks, annoying licensing minutiae, lethargic cloud orchestration, weird reoccurring tunneling issues, and a myriad of other tidbits I’m vaguely remembering which have all driven me completely bonkers on endless occasions.

Even with this self-reflection, we are never totally cleansed from bias. This often manifests in the form of unified networking stacks which MSPs and other IT professionals enforce in-order to streamline and standardize internal training and troubleshooting protocols. While this offers an operational advantage, it is effectively a form of self-induced vendor lock-in. This results in an adverse effect for customers who are liable to receive product recommendations that do not best match their context. The solution to this problem is simple: never accept the opinion of a single person or company. Instead, get second, third, or maybe fourth opinions, casting a wide net and capturing the perspective of many different professionals who preferably aren’t all drinking from the same well.

tl;dr:

“What router should I get” is a tricky question because it begs your use-case, environment, and risk profile. Furthermore, casual (free) advice is probably bad advice, and professional (paid) advice is still subject to bias.

“So… What router should I really get?”

So with all of that out of the way, let’s see if I can free myself from ever needing to think about this question again by answering it once and for all.

We’ll start with a simple follow-up question: “Are you paranoid?”

Advice for the Risk-Inadverse

If our subject isn’t totally disarmed by our follow-up question and confidently answers “No”, we can safely assume that they have a lax risk profile and have no reason to fear the technology that they use. This perspective comprises the vast majority of people who simply want the technology in their life to “just work” in the manner that they expect. Organizations fitting this mold view security as the means to the end of qualifying for a cyber insurance policy.

The appropriate follow-up advice for this cohort is extremely simple: “Consult with your local highest-rated computer repair shops and/or MSPs and obtain multiple quotes for networking solutions that fit your budget”

This response embodies the essence of what appropriate and earnest advice looks like in a casual, unpaid context. Of course, if you’re an IT professional being paid a salary and/or a commission to provide advice, stick to your own script and/or sales quotas. This advice (about providing advice) is intended for IT professionals like myself who don’t have any skin in the game anymore and who want to politely respond to requests for free advice neutrally and without committing to doing any unpaid work.

If the questioner insists on getting a specific hardware recommendation and doesn’t want to pay anybody to do any work, the response simply becomes: “Buy the highest-rated router from your preferred storefront that fits your budget”

Easy, right?

Advice for the Risk-Adverse

Things get a bit more complicated if the response to “are you paranoid” is anything other than “no”. Fortunately, this doesn’t come-up very often during casual discussion, and even when when it does, I personally enjoy using these opportunities to share my (possibly biased) views concerning network security.

The Case for Paranoia: You Are Not Safe

If you’re feeling anxious, paranoid, or otherwise concerned about your router selection, I want you to know that your feelings are valid. Time has proven that no vendor delivers a bulletproof solution in this space. Whether you’re a state actor engaged in sensitive work, victim of identity theft and/or ransomware, or even if you just watched a little too much Mr. Robot and have an urge to smash your Nest thermostat with a hammer, we all have a right and reason to harbor distrust toward the technology we are expected to use in our personal and professional lives.

While this distrust rightfully applies to all of the technology that we use, routers are especially suspect: They often directly face a huge attack surface (the Internet) and function as extremely potent attack vectors. As a result, routers are frequent targets in digital warfare (1, 2, 3, 4) and a lot of international effort goes into discovering and exploiting their vulnerabilities.

Vulnerabilities vary widely in their scope and severity. Since the technical details involving vulnerabilities can get pretty esoteric, it helps to have a standardized reporting and scoring method to help clearly communicate information to a broader audience. The Common Vulnerabilities and Exposures (CVE) system represents the most widely-used vulnerability reporting and identification method and is often used in-conjunction with the Common Vulnerability Scoring System (CVSS) to assign a standardized severity score on a scale of 0 to 10.

CVE IDs (often shortened to “CVEs”) are used to identify vulnerabilities. As an example, the CVE implicated in the notorious log4j exploit from 2021 is CVE-2021-44228 and has a maximum CVSS score of 10. CVEs are assigned by a certified naming authority (CNA) and while many large companies are registered to serve as CNAs for their own CVEs, in many circumstances CVEs are instead assigned by the MITRE Corporation or other third parties and researchers.

While not perfect, this system of reporting and documenting vulnerabilities, in my opinion, forms the single most important source of validation for the technologically anxious and skeptical. If you’re interested in a specific vendor’s products, but have security concerns that are ethereal and difficult to articulate, you can look-up the vendor in-order to get a running log of what they’ve been battling.

Picking a security-conscious vendor unfortunately isn’t as simple as taking all CVEs and their CVSS scores at face-value, as there are a handful of caveats with this system:

  • Undiscovered vulnerabilities will always exist, and discovered vulnerabilities are not always immediately reported to developers/vendors (Zero-day vulnerabilities)
  • Vendors may delay assigning CVEs to reported vulnerabilities, or may decline to assign an ID altogether (CNA rules section 7)
  • Vendors may assign inappropriate CVSS scores to CVEs (see NIST vs Microsoft, CVE-2021-26855)
  • Some vendors may have more CVEs simply by virtue of their relative popularity; as a user base grows it becomes a more valuable target, warranting greater resources being allocated toward discovering vulnerabilities.
  • CVSS scores lack the context and nuance necessary to function as an objective risk scale (see CVE-2021-21972 vs CVE-2021-26855; both featured extreme RCE and/or privilege escalation with identical CVSS ratings of 9.8, however their different attack surfaces resulted in vastly different outcomes for affected parties)

Despite these shortcomings, we can still use this system of reporting and the discourse surrounding the process to inform our decision-making when picking networking vendors who meet our security requirements. Rather than judge vendors by the frequency, nature, and severity of their CVEs, we should instead judge vendors by their behavior surrounding their CVEs. While every vendor at some point is going to encounter a high-risk CVE, the manner in which they respond to these threats reflects their their commitment to security.

You don’t get what you don’t pay for

In PC Magazine’s ranking of top home networking brands for 2024, ASUS ranked #2, very closely trailing the top entry on the list (TP-Link). I’ve personally held a mostly favorable view of ASUS as a manufacturer of computer hardware, and at some point in the past they started manufacturing routers. At the time of this writing, their offerings can be purchased from Amazon at prices ranging from $70 to $250+.

What is most notable about ASUS in my opinion is their implication in a security lapse involving their routers resulting in data belonging to thousands of customers being compromised. The lapse was egregious enough to warrant charges being filed by the FTC, who alleged in their complaint that it took eight months for ASUS to patch the offending vulnerability, all despite making strong security assurances in their marketing material.

Despite fumbling hard enough to warrant the scrutiny of a federal regulatory agency, we can fast-forward 10 years and see that ASUS remains a top seller of home networking equipment. How is this even possible?

Let’s start by illustrating an important division in the broader market for networking equipment. Vendors in this space can be assigned to one of two categories depending on their revenue model:

On one end, there is the consumer/home market. Popular brands include ASUS, D-Link, Linksys/Belkin, Netgear, TP-Link, Ubiquiti, and more. You can typically find these products at your local big box store (if you still have one) or through online storefronts like Amazon, eBay, newegg, etc. Vendors in this space acquire revenue through the initial point of sale for hardware and do not charge fees for firmware and security updates. If a subscription is offered at all, it is typically optional and tied to some tertiary function like cloud storage or advanced content filtering.

On the other end, there is the professional market. Popular brands include SonicWall, PaloAlto, Fortinet, Cisco/Meraki, and more. IT professionals are likely familiar with the terms “Small/Medium Business” (SMB) or “Enterprise” used to describe product offerings in this space. These products are typically purchased (or leased) directly from a vendor through an exclusive online storefront or through a sales representative. While vendors in this space vary widely in their point of sale practices, they universally acquire reoccurring revenue through licensing, service agreements, and/or subscription fees. Customers who fail to pay these fees may lose access to features and security updates, or in more extreme cases (Meraki) may experience a complete loss of hardware functionality.

Some vendors like toeing the line between these markets. Ubiquiti for instance is often presented as a “prosumer” option which I’ve personally seen deployed at many small businesses. In my opinion, they should be categorized as a consumer/home vendor because (to my knowledge) they do not charge reoccurring fees after the initial point of sale. I’m otherwise going to avoid talking about Ubiquiti at-length mostly because I don’t want to get sued.

While the products offered within these markets are often well-suited to their target demographics, if our focus is strictly on risk-aversion and network security, all else being equal, professional vendors are more likely to provide greater security assurances than consumer/home vendors for a myriad of reasons:

  • Professional vendors are more exposed to material loss: Since the clientele of professional vendors provide a revocable source of reoccurring revenue, there is risk of material loss if customers switch to competing vendors. This risk can in many circumstances be as great as tens of thousands of dollars in yearly revenue per customer. This specific risk is otherwise totally absent in the consumer/home market where customers wield no material leverage after the initial point of sale beyond the product’s return and warranty time windows.
  • Professional vendors are more exposed to reputational loss: The clientele of professional networking vendors are mostly comprised of IT professionals including IT directors, CTOs, and MSP representatives. This clientele is more likely than the general public to:
    • Correctly ascribe blame for a breach
    • Possess purchasing oversight for hundreds or thousands of routers and/or other networking infrastructure components
    • Carry sway when discussing vendor quality/reputation amongst other IT professionals in the workplace and on online communities/forums
    • Expect a longer lifecycle for core networking equipment (7+ years)
    • Primarily concern themselves with product stability and security
  • Consumer/home vendors are better poised to couch reputational scrutiny: The clientele of home networking vendors are mostly comprised of the general public, who are more likely than IT professionals to:
    • Incorrectly ascribe blame for a breach
    • Possess purchasing oversight for only a single household
    • Defer to product review/ranking on online marketplaces when ascertaining vendor quality/reputation
    • Accept planned obsolescence (2-3 years)
    • Primarily concern themselves with price, features, appearance, and ease-of-use

So, we can now put together a hypothetical timeline explaining how a vendor might manage fumbling a vulnerability for eight months while also managing to maintain market relevance in the long-run:

  1. A consumer/home networking vendor can expect $xx-$xxx in revenue per unit sold with no reoccurring revenue. This is a competitive market where priorities are centered around shipping products that compete on bases of price, features, appearance, and ease-of-use.
  2. In the pursuit of driving-up feature count, a vendor ships a new half-baked feature that introduces a severe vulnerability in their product line-up.
  3. The vulnerability is discovered some time later by third-party researchers who report their finding to the vendor.
  4. Since the vendor does not have revenue streams dedicated to security, solving the vulnerability represents a cost center warranting minimal resource allocation, resulting in the vulnerability remaining indefinitely unmitigated.
  5. Bloggers and tech journalists begin reporting on the issue, however the target demographic of these publications (IT professionals) does not match the target demographic of the product. (general public)
  6. Users impacted by the vulnerability may react in a variety of ways; many may have no clue that there is anything wrong with their router, while others may only perceive performance issues and decide to replace units that “run slow” due to broad acceptance of planned obsolescence. Users who correctly identify the vulnerability may leave bad reviews on storefronts in-retaliation, however due to rapid product release cycles, these reviews will quickly get buried as new models continue to be rapidly developed and brought to market.
  7. Fixing the severe vulnerability finally becomes a higher-priority task once imminent governmental regulatory action poses a material threat to the vendor.
  8. After paying lip-service to regulatory bodies and consenting to independent auditing, the vendor patches the original issue and continues developing and shipping products that compete on the bases of price, features, appearance and ease-of-use…

It isn’t my intention to single-out any specific router vendor, or even the entire market for consumer/home routers as a whole; these problems are intrinsic to the economics of all networked tech products where profit is entirely derived at the point of sale. “Security” is not a sexy feature that you can just plaster on a product description, but rather a commitment to addressing ongoing and evolving threats. Eventually, what you paid at the initial point of sale isn’t going to be enough to buy more developer time, so a vendor’s answer to security is going to involve selling you their latest thing. Nowhere is this more obvious than in the consumer market for smartphones where vendors arbitrarily drop support for older, but still perfectly functional models; if you want the latest iOS or Android security patches, you need to drop a couple hundred (or thousand) dollars for the newest thing.

By the same token, it isn’t my intention to down-play the broader consequences of these perverse market incentives. When security is treated as a cost center, the act of discovering vulnerabilities falls into morally ambiguous hands. ASUS maintains a “Hall of Fame” recognizing security contributions made by third-party organizations and researchers. Who this list fails to recognize are the countless advanced persistent threat actors who seek and discover vulnerabilities to use for malevolent and/or state-sponsored purposes that don’t get reported.

So if you’re paranoid and ask me what router you should get, I’m going to start by saying that you generally shouldn’t use anything from the consumer/home market because the economics of the market do not leave room for competition on the basis of security. Even when vendors in this space put security assurances in their marketing material, they’re unlikely to earnestly follow-through on these promises because they have no continued monetary incentive to do so after you click the check-out button.

You don’t always get what you do pay for

The professional market for networking equipment isn’t immune to scrutiny; since these vendors demand reoccurring service fees, their customers rightfully require corresponding security assurances. However, when a company ultimately answers to its shareholders above all else, customers may be left in the lurch paying for services that do not provide proportional value.

Fortinet in-particular has been a recent subject of scrutiny. In a 2022 article, Fortinet was criticized for delays in reporting a critical vulnerability and as recently as 2025 tech vloggers have been thoroughly documenting instances of the company fumbling CVEs. This is all despite the fact that licensing/renewal fees for Fortinet devices have reportedly far outpaced inflation, with one commentator on reddit reporting a ~35% renewal price increase after two years. This phenomenon isn’t unique to Fortinet and has similarly been reported against other vendors to varying degrees.

One major issue that professional networking customers face is their deep exposure to vendor lock-in. While a home customer can quite easily chuck an old router in the bin and replace it with a new one, when it comes to MSPs or large businesses, swapping-out networking equipment can be a herculean task. Even if an organization wanted to divest in one vendor and switch to another, they’re going to face significant costs; hundreds or thousands of pieces of old hardware will need to be sold-off at a loss, any money already spent on service agreements will evaporate, IT staff will need to be trained on how to install and use new equipment, and significant outage and troubleshooting windows will need to be scheduled to facilitate a massive networking overhaul. As a result, it should come as no surprise that many customers simply choose to accept vendor-imposed enshittification over enduring these hardships.

This unfortunately puts us between a rock and a hard place; if consumer/home networking equipment cannot be trusted on the basis of security, and if professional networking equipment cannot be trusted on the bases of value and risk of vendor lock-in, are there any alternatives that mitigate these issues or otherwise strike a balance?

You can’t trust code that you can’t read

Professional and consumer/home networking vendors are similar in-that the vast majority of the code they write is proprietary software. While there are arguably plenty of legitimate reasons for wanting to maintain a proprietary codebase, if you’re risk-adverse, you probably shouldn’t run code that you’re not allowed to read, especially when that code manages all of your network traffic.

While many people nowadays are familiar with the concept of free and open-source software (FOSS) and associated projects like Linux, Firefox and LibreOffice, there are also many FOSS router projects, including but not limited to:

Oftentimes when I’m engaged in conversations with other IT professionals or tech enthusiasts and the topic of FOSS software comes-up, I end-up hearing variations of an argument claiming that FOSS is somehow less secure because the code is “open for attackers to read and exploit”. Unfortunately this argument at-best comes from a place of ignorance, and at-worst a place of malice:

  • When this argument is made in-earnest, it generally comes from a misplaced understanding of the relationship between security through obscurity and security by design; in-reality, FOSS projects like the Linux kernel are an integral part of all of the technology that we take for granted and represent some of the most secure and rigorously-tested software in history… all despite due to the fact that anybody can read the source code. To quote NIST: “System security should not depend on the secrecy of the implementation or its components.”
  • When this argument is made insincerely, it serves as a vehicle for delivering FUD in-order to convince a listener to implement an expensive proprietary solution. The concept of free software is antithetical to the ethos of the sales representative: “How am I supposed to earn my commission if the product is free?”

When this argument comes-up it serves as a great signal to ignore anything else the speaker has to say. While there are plenty of legitimate arguments to be made against using FOSS which we’ll get to, the simple fact that the code is open for anybody to read isn’t one of them.

With that little rant out of the way, let’s look into some of the ways that free and open source router projects can help mitigate the pitfalls of their proprietary alternatives:

  • FOSS routers are fairly hardware-agnostic and typically allow users to re-use the same hardware when transitioning between different projects. This is in stark contrast to proprietary products sold by professional vendors where the bundled hardware and software is typically incompatible with any other combination of hardware and software.
    • Since consumer/home vendors face different market incentives, their products are often easy to modify, with the ability to install alternative firmware sometimes being marketed as a feature. As a result, if a consumer/home vendor is slow to solve a vulnerability, the issue can often be mitigated by replacing the stock firmware with a FOSS alternative.
  • If the maintainers of a FOSS project are slow to issue security updates, the broader community has the right to write and “push” software patches to the main branch on their own accord.
  • If the maintainers of a FOSS project refuse to commit security changes to the main branch, the broader community has the right to “fork” a project and go their own way. (Projects can be forked for many reasons, see OPNSense vs pfSense)
  • FOSS software is available without charge; while some vendors may monetize a project through support agreements, these are totally optional and not required to use FOSS software. Many projects receive support through grants, sponsorships, and/or developer time provided by organizations and/or government agencies.

As much as I would like to be able say that everyone should use free and open source routing software, there unfortunately are legitimate issues and trade-offs to consider:

  • Hardware compatibility is not universal; for instance, pfSense, OPNSense and VyOS are not currently compatible with ARM-based CPUs. While OpenWrt supports an extremely wide array of hardware, compatibility in some cases may be incomplete or non-existent.
  • You still don’t get what you don’t pay for; if a project is abandoned by all of its maintainers, the software will quickly lose any utility as new vulnerabilities go unresolved, forcing users to switch to other alternatives. (examples of defunct projects include m0n0wall, Zeroshell)
  • Professional networking vendors often have substantially greater access to resources and developer time than FOSS maintainers, potentially permitting greater security assurances within their proprietary codebases.
  • FOSS projects are not immune to backdoors; persistent state-sponsored actors can infiltrate projects and push malevolent updates in plain sight if the broader community isn’t paying attention.
  • Existing users of proprietary software may depend on vendor-specific features which may not be available in comparable FOSS projects.
  • Installing FOSS software on consumer/home market ARM-based routers is generally more difficult than using stock firmware and often comes with the risk of inadvertently bricking the device.

Despite these trade-offs, I would strongly recommend any of the listed FOSS projects. While they’re not going to suit all contexts, if you’re capable and willing to read documentation and have a spare router or PC lying around, you can avoid the inevitable security pitfalls of the consumer/home market while also avoiding the expense and lock-in risk of the professional market. Even if you don’t feel capable of doing the work yourself, any professional IT organization worth their salt will be able to give you a quote.

Whether or not you personally decide to use a FOSS router, there are plenty of additional steps you can take to improve your security posture.

It isn’t what you use, but how you use it

For security-conscious readers, the question “what router should I get?” is often far less important than “how should I configure my router?”. Even the most advanced device is going to be vulnerable to security breaches if it isn’t configured and used in a responsible manner. Equipment and associated routing software spanning all price ranges typically include features and settings that can be tweaked and adjusted to suit a variety of security postures.

Principle of Least Privilege

Principle of least privilege (PoLP) is easily the single most important and widely-implemented security feature of any system. The core premise is that members of a system should only possess the level of privilege they need to fulfill their role. This applies not only to computer systems, but to everyday life; you cannot legally drive on public roads without a drivers license or permit, nor can you fly a plane without a certificate, nor can you access confidential information without a security clearance.

These controls are valuable because security cannot exist if anybody has maximal privilege. Anarchy does not exist because everyone has everything to gain by consolidating privilege. Autocracies are insecure because the people they repress have everything to gain by deposing the holder of the scepter.

Conversely, these controls can become a hindrance since freedom cannot exist if nobody has any privilege. When bureaucracies fail to dispense lawful privilege and only exist for their own sake, they paralyze and destroy their host.

Principle of least privilege is fulfilled when a system achieves the correct balance between security and freedom that ensures the system’s long-term viability.

So, how does this concept translate to computer networking, or more specifically, router configuration?

Disable features that you don’t need

The first step in fulfilling PoLP involves eliminating unnecessary and/or superfluous privilege. Just because you can do something doesn’t mean that you should, and if a type of privilege doesn’t provide value or only does so at the cost of an unconscionable amount of security, it should be unilaterally precluded from use without exception. For example, no single member of the US armed forces has the authority to directly arm and launch a nuclear weapon at any target on their own accord. While it would certainly be technically possible to construct a mechanism (or “feature”) that permits this, doing so would be unwise due to the extreme security risks involved. Instead, the use of nuclear weapons in the US is guarded through a complex command chain including fail-safe mechanisms.

One argument I frequently hear against FOSS software is that many projects lack the features and capabilities of comparable proprietary products. While this assertion is starting to lose ground in a world where famous Youtubers are ditching Adobe Photoshop and switching to GIMP, in many contexts this argument still holds plenty of water, and I’ve personally encountered many situations where FOSS software hasn’t met the bar for a necessary task or workload.

This feature argument gets murky when it comes to routers. While feature creep is often used to describe bloated software that has outgrown its original purpose, when it comes to routers, this creep can become extremely dangerous, especially given the router’s unique position and role in a computer network. We can see evidence of this risk when considering the root sources of many CVEs:

  • The ASUS vulnerability discussed earlier and cited by the FTC back in 2014 specifically involved an “AiCloud” back-up feature. As recently as 2025, AiCloud was implicated in another critical CVE with a high CVSS rating of 9.2.
  • An aforementioned Fortinet CVE from 2022 with a high CVSS rating of 9.8 specifically implicated the FortiOS SSL-VPN service.
  • Another Fortinet CVE from 2023 with a high CVSS rating of 9.8 implicated the endpoint management service FortiClientEMS.
  • Palo Alto networks encountered a CVE with the highest possible CVSS score of 10 as recently as 2024 involving their GlobalProtect gateway.
  • SonicWall encountered a CVE in 2023 with a CVSS rating of 8.8 impacting their Global Management System (GMS), and as recently as 2025 their SSL-VPN client was reported to suffer an MFA bypass exploit.
  • A third-party add-on for pfSense firewalls called pfblocker-ng encountered a CVE in 2022 with a CVSS rating of 9.8, allowing unauthenticated remote code execution through the web management interface. (write-up from the group who discovered the bug)
  • KRACK is an exploitable flaw in the Wi-Fi standard discovered in 2017 that impacts the WPA2 security protocol. This is cited in a handful of CVEs and has been fixed in later Wi-Fi standards.
  • Universal Plug and Play (UPnP) is subject to numerous vulnerabilities (1, 2)

I could keep going but this list would never end. The problem with stacking features on features is that they inevitably turn into new attack vectors once their vulnerabilities are discovered. The takeaway is that in-order to maintain a better security profile through PoLP, you should only enable and use features that you absolutely need, since generally speaking, unless a feature is enabled, its associated CVEs won’t pose a direct threat to your environment.

Many of the vulnerabilities I listed specifically implicate client VPN services. I’m very aware that many corporate environments take this functionality for granted, especially in the wake of COVID in-order to facilitate WFH workflows. I would encourage any security-conscious reader to challenge this notion given the mountain of CVEs that directly implicate these services. With many organizations switching to cloud-hosted software and infrastructure, the role of the client VPN is fading and in my opinion it is becoming much more difficult to justify allowing users to build tunnels to corporate offices at-will, especially when many of these connections will originate behind potentially vulnerable home/consumer-grade hardware.

In some circumstances, it isn’t the VPN implementation itself that is impacted by a CVE, but rather all of the other half-baked services and features that vendors graft onto a single, bloated, catch-all package. Software like GlobalProtect and FortiClient have mutated far beyond their original purpose of brokering VPN connections and are now responsible for mobile device management, content filtering, endpoint protection, and more. It doesn’t matter how secure a router’s VPN implementation is if adjacent services that utilize the same client software leak vulnerabilities like a sieve. A system is only as secure as its weakest link, and when somebody sneaks satellite internet onto a warship, it no longer matters how many taxpayer dollars go into developing and enforcing the Navy’s security systems.

I could go on a whole other rant about the self-eating snake of endpoint protection, but to summarize my thoughts, installing a third-party rootkit on all of your endpoints is a concession in broadly prioritizing convenience (freedom) over real security. Please refer to the section “Advice for the Risk-Inadverse” if you’re still using Crowdstrike.

Once you’ve identified the core basket of required services that your router needs to provide, there are plenty of further steps that can be taken to further implement PoLP and improve security posture.

Narrow the scope for features that you do need

Privilege is usually provided granularly, rather than absolutely. A basic class C drivers license does not confer the right to drive a semi-trailer, nor does obtaining a recreational pilot certificate confer the right to pilot a 737. Security clearance is provided through the granular levels of confidential, secret, and top secret, with access generally limited to a specific scope of data.

Within the context of computer networks, PoLP is often used to describe the granularity of user privilege. For instance, while the right to use a computer is often taken for granted, in security-conscious corporate environments, user access to administrative rights is subject to PoLP; most people don’t need administrative access to their machine even if they think they do, and in the rare circumstance where it is actually required, privilege escalation should be provided carefully and sparingly. When privilege escalation is provided casually and automatically, data tends to get encrypted and held for a ransom.

User privilege applies to routers as much as anything else; if a user only needs to check router logs and traffic statistics, they should use a read-only account. However, since routers are uniquely positioned within a computer network, there are a handful of other best practices that need to be enforced to ensure that PoLP is fulfilled, with examples including but not limited to:

  • Limiting how and where the router management interface can be accessed
  • Limiting ingress and egress according to source, destination, and service
  • Segmenting internal traffic according to trust zones and limiting their communication with each other and with the Internet

The most egregious PoLP failures occur when the router management interface is left wide-open. Strong passwords alone are not good enough when practically every vendor has encountered a CVE specifically implicating this interface (PaloAlto, pfSense, SonicWALL, (see SNWLID-2019-0009), Fortinet) and while it is extremely convenient being able to access the management interface from anywhere in the world, to the rest of the world this makes for an equally convenient target to exploit. At a minimum, access to the management interface should be limited to prescribed and specific external sources. Ideally, it shouldn’t be open to the Internet at all and should only be accessible from your internal network. Even better would be relegating access to a trusted or “management” zone inaccessible to regular users. In even the least security-conscious environments, this tiny inconvenience pays dividends toward network security posture.

Many router vendors offer cloud orchestration and management platforms that allow an organization to manage and configure all of their routers through a single, usually web-based interface. These solutions provide convenience (freedom) at the cost of security, since they require that your routers’ management interfaces be exposed to the Internet (albeit with a limited scope) and also require implicit trust of the vendor’s proprietary cloud service. Professional vendors usually have strong monetary and reputational incentives to keep these platforms secure, however they’re not usually built with open design principles, and platforms such as FortiManager and SonicWALL GMS have suffered CVEs of varying severity in the past. While an organization managing hundreds or even thousands of firewalls might find these services crucial, in my opinion, a security-conscious organization of this size should have the manpower and resources available to develop an in-house orchestration service using Ansible or other tools.

After management interfaces, our next topic is network ingress. If your environment hosts services which need to be exposed to the Internet, whether it be your client VPN service or a Minecraft server, you’re going to have ports opened-up on your router’s firewall in-order to allow ingress to occur. By-default, when a port is opened, the associated service typically becomes exposed to the entire Internet. Simply changing the port number to a non-standard one is an example of bad security through obscurity since this does nothing to materially change the attack surface (the entire Internet). So, ideally and in-accordance with PoLP, ingress should ideally be restricted to the specific IP addresses or IP ranges that actually need to reach the service.

Of course, this isn’t going to work in all contexts. While my dynamic IP at home hasn’t changed in 2 years, some workflows involve very mobile users who will have different IPs on a day-to-day basis. This, coupled with the fact that IP addresses aren’t actually a great way to identify or authenticate users, also coupled with the fact that routers typically cannot read encrypted traffic, all serve as core drivers for zero-trust architecture. While narrowing allowed IP ranges will reduce the attack surface and should be exercised where possible, it is important to acknowledge the limitations of routers within the context of authentication and trust.

Egress can get a bit contentious because oftentimes the people who use your network expect to be able to reach anything and everything on the Internet all the time. The reality however is that most people and/or organizations only really need to reach a handful of external services to function adequately, and by restricting outbound access to the bare minimum, PoLP is attained. While some organizations may find this approach valuable, for many others it might represent too extreme a burden on the freedom of users, so it is important to strike a balance that best suits your specific risk profile.

An effective approach for many organizations involves broadly permitting egress, with the exception of specific destination domains, IP addresses and/or ranges deemed problematic. For instance, many US-based companies allow egress to other IP addresses and domains based within the US, with traffic to other countries being permitted on an as-needed basis within narrow scopes. While the US itself represents a huge attack surface, which may include threat actors from other countries operating via proxy, this still represents a substantially smaller attack surface than the entire Internet and represents a security improvement via PoLP. In an earlier article I discussed how this type-of filtering can be used to block ad-serving domains, which frequently serve as vectors for malware.

Finally, it is time to discuss network segmentation and trust zones. While what we’ve discussed so far has mostly involved limiting traffic flows between the router and the Internet, we can also use routers to define distinct sections of an internal network and limit traffic between them. On consumer/home equipment, this functionality often exists in its most rudimentary form through the “guest” network feature; in most cases, devices connected to the guest network have no privilege to communicate with devices on the primary or “trusted” network. Outside of consumer/home networking, this principle can be expanded-upon by defining subnets and VLANs, as well as wireless client isolation which can be used to more granularly separate devices and their traffic.

This functionality can help fulfill PoLP since the devices that sit behind a router do not necessarily need to be able to communicate with each other. With client isolation, if one device is compromised, the blast radius becomes limited to that single device, effectively preventing it from becoming a vector capable of infecting other local targets.

In circumstances where some devices need to be able to communicate with each other, groups of devices can be assigned to specific VLANs and subnetworks, allowing varying degrees of inter-group permissibility and/or isolation. IoT devices may only need to be able to communicate with the Internet, while CCTV devices may not require access to the Internet at all. The management interfaces to networking equipment can be relegated to a segment that isn’t accessible by any other segment, while web-facing traffic can reside in a segment configured to allow specific inbound connections while blocking most outbound connections.

While network segmentation by no means supplants identification and authentication, when compared to maximally-permissive “flat” networks, this practice can reduce internal attack surfaces and limit potential collateral damage, especially when some devices or services need to be exposed to greater risk than others.

Update your firmware

When a router CVE is discovered, the corresponding fix usually comes in the form of a firmware update. This falls under the broader umbrella of patch management and represents the most important reactive work IT teams are tasked with coordinating, scheduling, and installing; the longer a router is exposed to a vulnerability, the more likely it is to become infected.

As much as I would like to think that this should go without saying, experience has proven to me that the importance of updating firmware isn’t universally understood or respected. For a myriad of reasons ranging from ignorance, buck passing, or wilful non-compliance, at any time there are tens, if not hundreds of thousands of active and unpatched firewalls operating at homes and businesses. When these devices are eventually patched, in many cases it will already be too late, with some devices continuing to harbor backdoors for continuous exploitation by threat actors.

While strong adherence to principle of least privilege can mitigate the potential impact of many CVEs, organizations that don’t routinely patch their firmware are often the type that are allergic to downtime and give domain admin rights to managers. To organizations that do not care about security, backups are a cost center and PoLP is the thing that a doctor looks for during a colonoscopy. They will get ransomware, they will pay the ransom and ask their cyber insurance policy for reimbursement, and they don’t care that their customer data is now up for sale on the dark web.

But if you didn’t care about security, you would have stopped reading a long time ago. Here are some tips:

  • Allow automatic firmware updates whenever possible (Meraki is probably the best at this in my opinion)
  • Subscribe to firmware update alerts or other newsletters from your firewall vendor
  • Subscribe to CVE alerts concerning your router and any of the features it supports.
  • Run configuration backups before and after each firmware update
  • Maintain flexibility; figure out how you can handle 30-60 minutes of downtime
  • If you can’t handle 30-60 minutes of downtime, expect to spend an arm and a leg on high-availability infrastructure along with capable IT staff who are willing and responsible enough to use it correctly.
  • If you are contracting IT work out to an MSP, do not assume that they are going to keep your firewall firmware up-to-date unless your legal counsel can validate that the MSP Is materially liable for damages resulting from SLA failures involving CVEs.
  • If a firewall has been running a vulnerable firmware for an extended duration, do not assume that the device is still safe to use. There is no guarantee that an advanced backdoor will be removed following a firmware update or even a factory reset.

Don’t drive yourself insane

In 2021, Meta spent over $26M on the security detail for Mark Zuckerberg. While he is an exceptional case, it isn’t uncommon for other high-profile individuals to spend over a million dollars a year on personal security. While physical security including bodyguards and facilities likely comprise the primary component of a security detail, it isn’t a stretch to assume that digital resources also play a part; Zuckerberg probably has very sophisticated and actively-monitored networking equipment deployed at his residences to ensure his and his family’s digital safety. These systems are probably far beyond the capabilities and/or budgets of most individuals, let alone large businesses, and frankly it would be ridiculous of me to suggest that everyone go to these lengths in the name of security.

Yet, even with an unfathomably huge security budget, it is impossible to build a perfect silo. Even multinational organizations or governments with billions of dollars to spend on security are not safe from zero-day exploits. While keeping your firewall firmware up-to-date and adhering to the principle of least privilege will protect you from a large variety of threats, the proliferation of and presence of zero-day exploits reflect the reality that there are threats that are out of anybody’s control. There is no such thing as perfect security and there are diminishing returns with each digit added to the end of your security budget.

While this might seem alarming, fortunately most of us are not valuable enough to warrant a targeted attack; the most sophisticated zero-day exploits often require millions of (often taxpayer) dollars to discover and develop. Even for those of us who are worthy targets, none of the advice myself or anybody else could provide would be of any help. If a state-sponsored agency wants to compromise you digitally, they’re going to do it at all costs regardless of the specific router or other networking equipment you choose to install.

So maybe it really doesn’t matter what router you get; go buy whatever you want and stop worrying.