When Security by Design Becomes Security by Default: A Fortinet Reality Check
Ah, Fortinet—a name that sparks lively debates among IT professionals. Is it a bastion of robust security or a cautionary tale of preventable mistakes? While building secure products is no walk in the park, and everyone’s bound to slip on a coding banana peel occasionally, the type of flaws we’re talking about here go beyond forgivable human error. No, these are the kind of “what were they thinking?” moments that make you wonder if some companies have mistaken cybersecurity for an optional extra rather than a core responsibility.
Let’s dive into the juicy details, shall we?
The Comedy of Avoidable Errors
Let’s be clear: nobody’s criticising Fortinet for the odd misplaced comma in their code. We’re talking about hardcoded credentials, weak encryption, and other blunders that would make even a junior developer cringe. For example:
Hardcoded SSH Keys
One of Fortinet’s greatest hits involves shipping devices with hardcoded SSH keys. Yes, in 2025. Why generate unique keys on first boot when you can just bake them in and hope no one notices? Fortinet’s defence? Oh, they’ve got documentation that advises users to generate their own keys. How quaint! Because, of course, everyone diligently reads the manual and follows every recommendation to the letter, right? It’s almost as if they’ve outsourced basic security to their users. Efficiency, perhaps, but not the kind you’d hope for.
Authentication Shenanigans
Take CVE-2024-47575, a delightful example of “missing authentication for critical functions.” Fortinet’s official advice boiled down to: “Hey, just don’t use the default admin username, ‘admin,’ and you’ll be fine.” Brilliant. Problem solved, right?
Except, no. Not only does this ignore the need for multi-layered defences, but it also assumes attackers are too polite to try brute-forcing a username.
Spoiler alert: they aren’t.
Input Sanitisation? What’s That?
Improper input sanitisation during webpage generation and cross-site scripting issues are textbook examples of why secure coding practices exist. But who needs to validate input when you can simply cross your fingers and hope users don’t try anything malicious? That’s a gamble that hasn’t paid off, yet the hits just keep on coming.
Security by Default? More Like Optional Extras
Let’s talk about defaults because they’re where the rubber meets the road in security. A well-designed system assumes users might not be experts. It doesn’t ask, “Would you like to enable basic protections?” It turns them on by default. Fortinet, however, seems to operate on the assumption that its users are part-time security savants who thrive on combing through manuals to toggle every obscure setting to “safe.”
Case in point: management interfaces that, if exposed to the internet, become a flashing “welcome” sign for attackers. Sure, Fortinet warns against this in their documentation, but shouldn’t the default be secure? Asking users to secure the product you sold them is like a car manufacturer saying, “The brakes are optional, but we highly recommend them.”
The Million-Dollar Question
Does Fortinet know about these flaws? Of course, they do. They even patch some of them. But here’s the kicker: the same types of vulnerabilities keep popping up. It’s like watching a sitcom where the characters never learn from their mistakes. Entertaining for the audience, perhaps, but not so much when the stakes are your organisation’s security.
Fortinet is a billion-dollar company. Surely, it could afford to invest in better testing, more rigorous development practices, or maybe even—wild idea—proactive pen-testing. But why bother when the revenue keeps rolling in? Where’s the incentive to improve if users aren’t voting with their wallets?
It’s a classic case of “if it ain’t broke… oh wait, it is, but who cares?”
The Bigger Picture: Why This Matters
Sarcasm aside (briefly), Fortinet’s recurring flaws highlight a larger issue in the cybersecurity industry: the disconnect between marketing promises and real-world security. When companies focus more on shipping products than securing them, it’s the end users who pay the price. Whether it’s a missed patch, a default password, or an admin interface left exposed, the cumulative effect of these oversights can be catastrophic.
And yet, the solution isn’t rocket science. Secure defaults. Rigorous testing. Transparent communication. These aren’t groundbreaking ideas—they’re just good practice. Fortinet, and others like them, need to stop treating security as an afterthought and start building it into their products from the ground up.
Final Thoughts: Is Fortinet That Bad?
Is Fortinet really that bad? Well, it depends. If you measure “bad” by the number of critical flaws, questionable decisions, and preventable mistakes, they’re not exactly covering themselves in glory. But if you measure it by profits, they’re smashing it. And therein lies the rub: until customers demand better, companies have no reason to change.
So, is Fortinet the villain of this story? Not entirely. They’re just playing the game the way the industry allows. But as professionals, it’s on us to push for better—to demand products that are secure by design, not secure by luck.
