I started working with hospital networks about 10 years ago. I thought I understood network security. Then I walked into the imaging department of a 400-bed hospital and saw a CT scanner running Windows XP connected directly to the hospital LAN. Not air-gapped. Not segmented. Sitting on the same flat network as the patient management system, the billing server, and the administrative workstations.

When I asked why, the radiology IT manager said: “The manufacturer says it can’t run anything newer than XP. And the scanner cost ₹3.5 crore. We can’t replace it for another 4 years.”

That’s the reality of healthcare cybersecurity: you’re securing a network where most of the devices were designed before modern security threats existed, and the consequences of a breach aren’t just data loss — they’re patient safety incidents.

The Three-Headed Problem: DICOM, HL7, and Unpatchable Devices

Hospital networks have three architectural realities that make them fundamentally different from enterprise networks:

DICOM (Digital Imaging and Communications in Medicine): The protocol that medical imaging devices (CT, MRI, X-ray, ultrasound) use to store, retrieve, and transmit images. DICOM was designed in the 1990s for interoperability, not security. It transmits in cleartext by default. Authentication is optional. Access controls are primitive. A DICOM viewer on a compromised workstation can browse every image on the PACS server without any authorisation check.

HL7 (Health Level 7): The protocol that laboratory systems, pharmacy systems, patient management systems, and EMRs use to exchange data. Lab results, medication orders, patient demographics, admission/discharge/transfer notifications — all flowing over HL7. Like DICOM, HL7 was designed for reliability, not security. No encryption. No authentication. No integrity checking. An attacker on the hospital LAN can inject fake lab results, modify medication orders, or intercept patient data — all via HL7.

Unpatchable devices: Medical devices have a lifecycle of 7-15 years. They run operating systems that are often 10-20 years old. They require FDA/CDSCO certification for any software change — which means even a security patch requires months of validation and recertification. Many devices run Windows 7 Embedded, Windows XP Embedded, or proprietary real-time OSes that have been end-of-life for years. They cannot receive security updates. And they’re connected to the network because they need to send images, lab results, and patient data to other systems.

What I’ve Learned From Securing Hospital Networks

1. You Cannot Secure What You Cannot Inventory

The first thing I do in any hospital engagement is a passive network discovery — not active scanning, because active scanning can crash medical devices. We use passive monitoring (NetFlow/sFlow, port mirroring, or SPAN ports) to identify every device on the network without sending a single packet to a medical device.

The results are always surprising. In a recent 600-bed hospital, passive discovery found 47 devices that weren’t in any asset inventory — including an infusion pump server that had been running unnoticed for 3 years.

2. Network Segmentation Is Non-Negotiable

Medical devices should never be on the same network as administrative workstations. End of story. I design hospital networks with the following minimum segmentation:

• VLAN 10 — Medical Imaging (DICOM): CT, MRI, X-ray, ultrasound, PACS server, DICOM viewers. Only DICOM traffic permitted. No internet access for imaging devices.
• VLAN 20 — Lab Systems (HL7): Laboratory analysers, LIS server, HL7 interface engine. Only HL7 traffic permitted. No general internet access.
• VLAN 30 — Patient Management: HMS/EMR servers, patient registration, billing. Limited to authorised clinical and admin staff.
• VLAN 40 — Building/IoT: HVAC, access control, CCTV, building management. Isolated from all clinical VLANs.
• VLAN 50 — Guest/BYOD: Patient and visitor Wi-Fi. Internet only. No access to any clinical VLAN.
• VLAN 60 — Administrative: Staff desktops, printers, file servers. Strictly controlled access to clinical VLANs via application-specific proxies, not routed connectivity.

Between each VLAN, FortiGate firewall policies enforce the minimum required access. An imaging workstation can talk to the PACS server (DICOM port 11112 only). It cannot talk to the lab system. It cannot talk to the patient database. It cannot browse the internet.

3. Replace Authentication With Microsegmentation (Where You Can’t Patch)

You can’t patch an MRI scanner running Windows XP. But you can ensure that the only thing it can talk to is the PACS server — by MAC address, by switch port, by application port. An attacker who compromises the hospital admin network can’t reach the imaging VLAN because there is no route. Even if they physically plug into a port in the imaging department, 802.1X authentication drops them into a quarantine VLAN until the NAC system verifies their identity and device compliance.

4. Monitor for Anomalous Medical Device Behaviour

Medical devices have very predictable traffic patterns. A CT scanner sends DICOM images to the PACS server. An infusion pump sends status updates to the pump management server. An HL7 interface engine forwards lab results to the EMR. If any of these devices suddenly starts communicating with an unfamiliar IP, sending data at an unusual time, or attempting to reach the internet — that’s an incident.

A SIEM with baselining capabilities (or PrahiX Ora’s anomaly detection) catches these deviations. In one deployment, we detected a PACS server that had been compromised — it was exfiltrating DICOM images (patient names, scan dates, diagnostic details) to an external IP every night at 2 AM. The hospital’s existing monitoring hadn’t caught it because “the PACS server is supposed to send images.” Yes — but not to a server in Eastern Europe.

The Regulatory Angle: DPDP Act and Healthcare

Healthcare data is “sensitive personal data” under the DPDP Act. The thresholds for breach notification and penalties are higher for healthcare than for general personal data. If a hospital network is compromised and patient data is exfiltrated — including medical images, diagnostic reports, and treatment histories — the Data Protection Board can levy penalties of up to ₹250 crore.

Given that most hospital networks have significant security gaps (unpatched devices, cleartext medical protocols, flat network topologies), the regulatory risk is substantial. The good news: the DPDP Act’s “reasonable security safeguards” requirement aligns perfectly with the segmentation and monitoring practices I’ve described. A hospital that has implemented proper VLAN segmentation, 802.1X, and SIEM-based monitoring can demonstrate that it took reasonable steps to protect patient data — even if a breach occurs.

What I’d Tell Every Hospital Administrator

Hospital cybersecurity isn’t an IT problem. It’s a patient safety problem. An attacker who modifies a lab result in the HL7 stream could cause a patient to receive the wrong medication. An attacker who encrypts the PACS server could delay a cancer diagnosis by days. An attacker who takes down the hospital management system could prevent admissions during a mass casualty event.

The threat model for healthcare is different from any other sector. The devices are older, the protocols are less secure, the consequences are more severe, and the budgets are tighter. But I’ve seen 600-bed hospitals transform their security posture with a phased approach: segment first, monitor second, automate third. No multimillion-rupee projects. Just good architecture, consistently applied.

And the CT scanner running Windows XP? It’s still there. But it’s on its own VLAN, firewalled to only talk to the PACS server, monitored by our SIEM for any deviation from its baseline behaviour. It can’t reach the internet, the patient database, or anything else on the hospital network. The manufacturer still won’t patch it. But it’s no longer the hospital’s biggest security risk — because the architecture around it changed.

Sanjay Seth has designed network security architectures for Indian hospitals since 2015. He’s the CEO of P J Networks and a specialist in healthcare IoT security.

The post Securing Hospitals — What DICOM and HL7 Taught Me About Unpatchable Devices appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

I’ve designed, deployed, and managed SD-WAN architectures across this country — from multi-site manufacturing plants in Gujarat and Tamil Nadu to BFSI data centres in Mumbai and BPO campuses in NCR. The conditions that kill uptime in India are specific: monsoon season link degradation, last-mile provider variability, power fluctuations at remote sites, and the sheer complexity of managing 15-50 branch connections with different ISPs, different SLAs, and different reliability profiles.

Here’s the Fortinet SD-WAN architecture I actually deploy — the one that delivers 99.98% measured uptime over 18 months across a 23-site manufacturing deployment.

The Architecture: FortiGate SD-WAN with Active-Active Load Balancing

The core of a high-uptime SD-WAN is active-active multipathing. Every site has at least two WAN links — typically one primary (leased line/MPLS) and one backup (broadband/4G/5G). The FortiGate at each site load-balances traffic across both links simultaneously, and if one link fails, traffic fails over to the remaining link in under one second.

Hardware stack per site:

• FortiGate 80F-120G (depending on site size) — SD-WAN edge
• FortiSwitch — local switching
• FortiAP — local Wi-Fi (optional, depending on site)
• Two WAN circuits from different providers (never the same ISP for primary and backup — I learned that the hard way when a single ISP’s fibre cut took down all links at a critical site)

Central stack:

• FortiGate 600F/900G at data centre — SD-WAN hub
• FortiManager — central configuration management (single pane for all 23+ sites)
• FortiAnalyzer — central logging, reporting, and compliance (180-day log retention)

How SD-WAN Prevents Outages (Not Just Bandwidth Aggregation)

Most people think SD-WAN is about bonding links for more bandwidth. That’s table stakes. The real value is in how it handles link degradation — and that’s where the 99.99% uptime comes from.

Real-time link quality monitoring: FortiGate SD-WAN measures latency, jitter, and packet loss on every WAN link every 100 milliseconds. It doesn’t wait for a link to fail — it detects degradation. If a leased line’s latency jumps from 5ms to 50ms (classic monsoon fibre degradation), the FortiGate redirects latency-sensitive traffic (voice, video) to the backup link before users even notice.

Application-based routing: Different applications get different paths based on their sensitivity. VoIP and video conferencing get the lowest-latency path. Bulk data transfers get the highest-throughput path. Guest internet traffic gets the backup link to preserve primary link capacity for business traffic.

SLA-based steering: Every application has an SLA contract. If the primary link fails to meet the SLA (e.g., VoIP requires <40ms latency and <10ms jitter), traffic is automatically steered to the secondary link. The steering happens per-flow, not per-connection, so a single voice call doesn't break during failover.

Automatic link remediation: When a link degrades, the FortiGate can automatically fail over AND raise a ticket with the ISP simultaneously. This is where integration with your NOC matters — the ISP gets an automated notification before users start complaining.

The Real-World Numbers (23-Site Manufacturing Deployment)

Over the last 18 months, this architecture handled:

• 47 total link failures across all sites (ISP outages, fibre cuts, power failures at last-mile exchanges)
• Mean time to detect: 1.3 seconds (all detected by SD-WAN link quality monitoring)
• Mean time to failover: 0.8 seconds (per-flow, hitless for most applications)
• User-noticeable downtime: 47 minutes total across all sites in 18 months (that includes the time it took for both links to fail simultaneously — which happened twice)
• Measured uptime: 99.98% (the 0.02% gap was the double-link failures)

Compare this to the traditional MPLS-only architecture it replaced: an average of 18 hours of outage per site per year from single-link failures alone.

The Mistakes I’ve Made (So You Don’t Have To)

1. Same ISP for primary and backup. I did this once. A single fibre cut near a major junction took down both links because they shared the same physical infrastructure for the last mile. The backup link wasn’t a backup — it was a second connection on the same vulnerable path. Always use different ISPs, preferably different medium types (fibre + 4G/5G).

2. Not testing the backup link under load. A 4G backup link that works fine for the monthly test can collapse when 50 users hit it simultaneously. We now run quarterly load tests that simulate full failover scenarios. The backup link needs to handle 100% of business-critical traffic, not just 20%.

3. Neglecting the management plane. The SD-WAN itself is resilient. But if the central management (FortiManager) or the VPN overlay goes down, you lose visibility and control. We now deploy redundant FortiManagers and run the SD-WAN overlay across two independent VPN hub FortiGates.

4. Not planning for asymmetric routing. With active-active multipathing, return traffic can take a different path than outbound traffic. This breaks stateful inspection unless you configure your FortiGate for asymmetric routing properly. The fix: use session-based forwarding instead of flow-based, and configure your firewall rules to expect asymmetric traffic.

5. Overlooking the last mile. The SD-WAN architecture is only as good as the physical infrastructure at each site. We’ve had to upgrade last-mile fibre terminations, replace aging media converters, and install UPS units at smaller sites to protect the CPE from power fluctuations. SD-WAN doesn’t fix bad cabling or power.

What I Recommend for Indian Enterprises

If you’re running traditional MPLS and considering SD-WAN, here’s my honest assessment:

• For 5-20 sites with MPLS: SD-WAN gives you immediate uptime improvement and 40-60% WAN cost reduction by replacing expensive MPLS with broadband + 4G backup. The ROI typically hits within 12-18 months.
• For 20-100+ sites: The management simplification alone (FortiManager vs. logging into each site separately) is worth the migration. Add in the uptime improvement and bandwidth economics, and it’s a no-brainer.
• For 1-5 sites: SD-WAN is still valuable for uptime and cost, but the management overhead of centralised FortiManager may not be worth it for very small deployments. Use FortiCloud management instead.

99.99% uptime isn’t a marketing claim in this architecture. It’s a measurable outcome of designing for the failure modes that actually happen in Indian network environments — not the sterile conditions of a vendor demo lab.

Sanjay Seth has been building Indian enterprise networks since 1992. He’s deployed Fortinet SD-WAN across manufacturing, BFSI, and government sectors.

The post 99.99% Uptime SD-WAN — The Architecture I Actually Deploy appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

I’ve responded to ransomware incidents across manufacturing, BFSI, healthcare, and government. I’ve watched teams make decisions in the first hour that determined whether the recovery took three days or three weeks — and whether the ransom was ever a consideration or never an option.

Here’s what I’ve learned about those first sixty minutes. It might save you a very long night.

Minute 0-5: You Realise It’s Not a False Positive

The alert comes in. Files are being renamed to .locked, .encrypted, or something similarly obvious. The EDR is screaming. The SIEM is lighting up. The user who was working on that spreadsheet is now staring at a ransom note.

The first impulse is panic. The second — and this is the one that causes the most damage — is to start clicking around, logging into random consoles, and trying to “see what’s happening.”

Stop. Do not browse the network from an uninfected machine that has administrative privileges. I’ve watched incident commanders accidentally spread the ransomware by logging into a domain controller from a compromised workstation segment. The ransomware was already on that segment. The admin’s credential cache was harvested within seconds of authentication.

Instead: verify the alert from a trusted, isolated admin workstation. Confirm with your EDR/SIEM that this is a genuine ransomware event, not a false positive from a security test or a script gone wrong.

Minute 5-15: Containment — The Decision That Costs or Saves You

This is the most critical window. Every minute the ransomware stays connected to the network, it encrypts more shares, compromises more credentials, and spreads laterally.

The orthodox playbook says: pull the plug on the affected segment. Not politely. Not with a change request. Pull the switch port, disable the VLAN, block the communication at the firewall.

But it’s not that simple. What if the affected segment runs your production line? Your ERP system? Your hospital’s patient management system?

This is where knowing your network architecture pays off. If you’ve already segmented your network (see Day 6 on zero trust), you can contain a single segment without taking down the entire business. If you haven’t segmented, you’re choosing between letting the ransomware spread or taking down the whole network — and neither option is good.

The containment decision I’ve seen work:

• At the FortiGate, block all traffic from the affected VLAN to any other VLAN
• Keep internet access for the affected VLAN (sometimes the ransomware needs C2 to proceed — blocking C2 can freeze the encryption process)
• Isolate the affected endpoint by disabling its switch port
• If domain controller compromise is suspected: disable the domain admin account and change the KRBTGT password

Minute 15-30: Triage — What’s Actually Encrypted?

Now you need to understand the scope. Don’t guess — verify.

• Check your backup system first. Is it reachable? Are the backups intact? This determines whether you’ll ever consider paying a ransom. If your backups are good and offline (the immutable, air-gapped kind), you have options. If your backups were on the same network and got encrypted too, you’re in a very different situation.
• Check the ransomware variant. Your EDR or a sample analysis can often identify the ransomware family. Some variants have known decryption tools (NoMoreRansom project). Some are lockers that don’t actually exfiltrate data. Some are double-extortion — they’ve already sent your data to their servers and will leak it if you don’t pay.
• Check for data exfiltration. Look at your firewall logs for large outbound data transfers from the affected segment in the hours before the encryption started. If data was exfiltrated, you have a DPDP Act reporting obligation within 72 hours.

Minute 30-45: Communication — Who Needs to Know

Silence is the enemy at this stage. A structured communication cascade prevents chaos:

• CEO/MD: “We have a cybersecurity incident affecting [scope]. Our team is containing it. We expect to have an update in 60 minutes. Current assessment: [critical/moderate/minor].”
• Legal counsel: Brief them on the situation, especially if data exfiltration is confirmed. DPDP Act breach notification clock is ticking.
• IT team: Clear instructions on who does what. One incident commander. No freelancing.
• PR/comms (if applicable): Prepare a holding statement. Don’t send it yet — but have it ready.
• Insurance: Notify your cyber insurance provider. Many policies require notification within 24 hours of discovery. They’ll also have a panel of incident response firms on retainer.

I’ve seen companies lose hours because nobody knew who was authorised to make containment decisions. Pre-agree on an incident commander before the incident happens.

Minute 45-60: Engage the Cavalry

By now you should have:

• Containment in place
• Scope assessment underway
• Backup integrity confirmed (or confirmed missing)
• Ransomware variant identified (or sample isolated for analysis)
• Leadership briefed

If you don’t have in-house incident response capability, this is when you bring in the experts. A good IR team can accelerate recovery by days — sometimes weeks — because they’ve seen your specific ransomware variant before and know the fastest recovery path.

If you do have in-house capability: start the recovery plan. Restore from clean backups to isolated infrastructure. Don’t restore to the same network — the attacker may still have persistence mechanisms that survived the encryption event.

The Pattern I’ve Seen Repeat

After responding to dozens of ransomware incidents, here’s the pattern that separates 3-day recoveries from 3-week ordeals:

• Good outcomes: Segmented network, immutable backups, documented IR plan, trained team. Incident contained in under 30 minutes. Recovery from backup in 24-72 hours. No ransom paid. No data leaked.
• Bad outcomes: Flat network, backups on same domain, no IR plan, heroics instead of process. Incident spreads to entire organisation. Recovery takes 2-6 weeks. Ransom paid (often unsuccessfully — only 26% of organisations that pay get all their data back according to Sophos 2024). Data leaked on dark web. Regulatory fines follow.

The difference isn’t luck. It’s preparation. And it’s entirely within your control — before the first alert comes in.

Sanjay Seth has responded to ransomware incidents across Indian enterprises since 2001. He’s the CEO of P J Networks and architect of the PrahiX Ora unified NOC/SOC/SOAR platform.

The post Ransomware in Under an Hour — What I’ve Learned About the First 60 Minutes appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

Everyone is talking about Wi-Fi 6E as a speed upgrade. They are missing the point.

Yes, the 6 GHz band gives you more spectrum, lower latency, and higher throughput. But if you are deploying Wi-Fi 6E just for speed, you are leaving the real value on the table. The most important upgrade is not the radio—it is the security model. I have been designing wireless networks since 802.11b, and Wi-Fi 6E is the first generational upgrade where the security improvements matter more than the throughput numbers.

The Old Model: WPA2 and the PSK Problem

For the last 15 years, most enterprise Wi-Fi deployments have used WPA2 with a Pre-Shared Key (PSK). One password for the entire network. Every employee, every guest device, every IoT sensor—all authenticating with the same shared secret. I have walked into corporate offices where the Wi-Fi password is printed on a sticker on the reception desk and shared with everyone who walks through the door.

This is a security disaster we have quietly accepted:

• Key compromise: When an employee leaves, you either change the PSK and reconfigure every device, or accept that a former employee can still decrypt your traffic. Most choose the latter. I have audited networks where the Wi-Fi password has not changed in 5+ years.
• No individual accountability: If someone launches an attack from inside, you cannot trace which user was responsible. Everyone used the same key.
• IoT devices share the same network: Temperature sensors, IP cameras, access control panels—all on the same SSID as the CEO’s laptop. If any is compromised, the attacker is past your perimeter.
• No device posture check: Any device with the password gets full network access, regardless of whether it is patched or even company-owned.

Every penetration test I have run in the last decade uses the same vector: capture a WPA2 handshake, crack the PSK offline, get on the corporate network, and scan for lateral movement. Tools like aircrack-ng make this trivial. A moderately powerful GPU cracks a weak PSK in hours.

What Wi-Fi 6E + WPA3 Actually Fixes

Wi-Fi 6E mandates WPA3 certification. WPA3 is not just a minor improvement—it fundamentally changes the authentication model. The Wi-Fi 6E security upgrade is baked into the standard, not bolted on as an afterthought. This is the first time a Wi-Fi generation has made a mandatory security leap alongside a radio leap.

Simultaneous Authentication of Equals (SAE): Instead of a shared PSK, WPA3 uses SAE—a handshake resistant to offline dictionary attacks. Even with the full handshake captured, the password cannot be cracked offline. This eliminates the decade-old attack chain that defined Wi-Fi compromise. For wireless security, this is the biggest improvement since WPA replaced WEP.

Opportunistic Wireless Encryption (OWE): Every client gets its own encryption key. Even on an open network, each device’s traffic is encrypted individually. An attacker capturing wireless packets cannot decrypt anyone else’s traffic. This is a game-changer for guest networks—you offer an open SSID with OWE encryption, convenient for users and secure for the network.

Enterprise WPA3 with 802.1X: WPA3-Enterprise integrates with 802.1X and RADIUS. Every user authenticates individually. When an employee leaves, disable their AD account and Wi-Fi access dies immediately. The RADIUS server also pushes VLAN assignments per user—finance on the finance VLAN, IT on the IT VLAN—all dynamically, without manual AP configuration.

The Real-World Deployment I Designed

Last year, I designed a campus Wi-Fi 6E deployment for 1,200 users across three buildings. Here is what we built:

• Three SSIDs: Corporate (WPA3-Enterprise + 802.1X against Azure AD), Guest (OWE), IoT (WPA3-Personal, unique PSK per device class via FortiNAC)
• Dynamic VLAN assignment via RADIUS: Finance users land on the finance VLAN, IT on IT, contractors on a restricted VLAN. The user just connects; the network decides the segment based on identity.
• Device posture checks via FortiNAC: Unpatched devices are quarantined to a remediation VLAN until they pass compliance.
• IoT segmentation with firewall enforcement: Each IoT class has its own VLAN with firewall rules permitting only the specific traffic each class needs. A compromised camera can only reach its NVR server.

The result: 1,200 users, 300+ IoT devices, zero wireless security incidents in 18 months of operation. The architecture did what it was designed to do.

Common Mistakes I See in Wi-Fi 6E Deployments

Even with the right hardware, I see the same mistakes: falling back to WPA2 because it is “easier,” using PSK on the 6 GHz radio, not upgrading RADIUS to support EAP-TLS, and putting IoT devices on the corporate SSID. All of these waste the security upgrade.

What This Means for Your Next Wi-Fi Refresh

If you are planning a Wi-Fi refresh, here is what I would recommend based on deployments I have done and mistakes I have seen:

1. Do not buy Wi-Fi 5 or Wi-Fi 6-only hardware in 2026. The price delta to Wi-Fi 6E is negligible, and you lock yourself out of WPA3 and its security improvements. The hardware will be in your walls for 5-7 years.
2. Plan for WPA3-Enterprise from day one. Deploy 802.1X with RADIUS against your identity provider. The setup takes 2-3 weeks but is transformative.
3. Segment your IoT devices. Use a separate WPA3-Personal SSID with per-class PSKs and firewall rules enforcing least-privilege communication.
4. Use OWE for guest access. An open SSID with per-device encryption beats a shared password that everyone in the lobby can see.
5. Upgrade your RADIUS and PKI infrastructure. WPA3-Enterprise with EAP-TLS needs a certificate authority. If you do not have one, now is the time.

Wi-Fi 6E is not about speed. It is about fixing a security model that has been broken since the first enterprise AP was deployed. Do not waste the upgrade on faster file transfers. Use it to build a wireless network that does not keep you up at night.

Sanjay Seth has designed wireless networks since the 802.11b days. He has deployed Wi-Fi 6E across manufacturing, healthcare, and enterprise campuses across India. If your Wi-Fi refresh plan only talks about speed and not security, you are having the wrong conversation entirely.

The post Wi-Fi 6E Is a Security Upgrade, Not a Speed One appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

That is the first question every CFO asks when you bring up zero-trust architecture. And if you answer with acronyms like ZTNA, SASE, microsegmentation, or identity-aware proxying, you have already lost the conversation. The CFO does not care about the architecture. They care about the outcome. And the honest answer is better than you think—if you explain it right.

What Zero Trust Actually Means (In Terms a CFO Cares About)

Here is how I explain it: Zero trust means nobody gets access to anything on your network just because they are already inside the building.

Think about your office building. Today, if someone walks through the front door (the firewall), they can walk to most rooms without being checked again. They can open the server room. They can plug into a data port in the conference room. They can access the finance server just because they are on the same network segment.

Zero trust changes that. Every door requires a fresh badge swipe. Even if you are already inside, you cannot access the accounting system unless you specifically have permission—and your device proves it is not compromised. The CFO gets this immediately, because physical security works the same way and they have already budgeted for that.

When I explain zero trust to a CFO, I start here. Not with architecture jargon. With the simple idea that internal access should be as controlled as external access. That clicks every time.

The Cost Side: What You Will Actually Spend

Let me give you a realistic budget, not a vendor’s pitch deck. These are numbers from actual deployments I have led or advised on in the last two years:

• For a 200-person company: ₹25-40 lakh for the initial architecture (FortiGate with ZTNA, NAC, 802.1X-capable switching) plus ₹8-12 lakh per year in licensing and management
• For a 500-person enterprise: ₹60-90 lakh upfront, ₹20-30 lakh per year ongoing. This typically includes FortiGate 200F or 400F pairs at the core, FortiNAC, FortiAuthenticator, and managed switches at each distribution point.
• For a 1000+ person multi-site operation: ₹1.5-3 crore initial, ₹40-60 lakh per year ongoing. Expect FortiGate 600F/900G pairs, full FortiNAC deployment, redundant FortiAuthenticator, and SD-WAN overlays.

Those numbers include hardware, deployment, configuration integration with your existing Active Directory, and three months of operational handholding. They are not cheap. The alternative is cheaper only until the first breach. I always break down the ZTNA ROI line by line so the CFO can see exactly where the money goes and what risk it retires.

The ROI Side: What You Save

The numbers that matter in a security budget conversation:

• Average breach cost: The IBM Cost of a Data Breach 2024 report puts the global average at $4.88 million. In India, a mid-size enterprise breach runs ₹12-20 crore. Zero trust prevents the lateral movement that turns one compromised credential into a full network compromise.
• Lateral movement prevention: 70-80% of ransomware attacks spread laterally after initial access. Zero trust stops that. A compromised workstation stays contained to its VLAN.
• Compliance cost reduction: DPDP Act compliance requires data access controls and audit trails. Zero trust delivers these without a separate project, saving ₹5-15 lakh in consulting fees.
• Insurance premium reduction: Verified ZTNA implementations report 15-25% lower premiums. On a ₹50 lakh annual premium, that is ₹7.5-12.5 lakh saved per year.

The Alternative They Are Not Considering

Here is what most mid-size companies actually do: nothing. Flat network, maybe a VLAN or two, a firewall at the edge, and hope. A single ransomware incident at an Indian manufacturer—production down for a week, forensic investigation, regulatory filings, DPDP breach notification—costs ₹2-5 crore in direct expenses and another ₹5-10 crore in lost business. I saw this happen to a client last year. Ransomware spread from a receptionist’s desktop to the ERP server in 45 minutes. Cost: ₹3.2 crore. The zero-trust deployment they are now doing costs ₹35 lakh. The math is not complicated.

How to Present This to the Board

When I prepare a board presentation on zero trust, I follow a simple structure:

Slide 1: The incident we are preventing—one case study, specific numbers, no jargon.

Slide 2: The solution in plain language—no device or user trusted by default.

Slide 3: The phased cost—three smaller numbers across 12 months, each with its own risk reduction.

Slide 4: The ROI—breach cost avoided vs. deployment cost. Payback period under 18 months.

I have presented this to boards at manufacturing, healthcare, and financial services firms. The conversation shifts from “why” to “how fast” every time.

How to Start Without a Multi-Crore Project

The biggest mistake is treating zero trust as all-or-nothing. Start with one segment. Prove it works. Then expand.

Phase 1 (~₹8-12 lakh): Deploy NAC and 802.1X on your core switching. Every device authenticates before it gets network access. This alone stops 60% of lateral movement threats. Timeline: 4-6 weeks.

Phase 2 (~₹12-20 lakh): Implement microsegmentation. Create VLANs for finance, HR, production, guest, and IoT. Apply least-privilege firewall rules between them. This contains any breach that gets past Phase 1. Timeline: 6-8 weeks.

Phase 3 (~₹10-15 lakh): Deploy ZTNA for remote and third-party access. Eliminate your VPN. Every session is authenticated and authorized individually. This closes the remote access vector entirely. Timeline: 4-6 weeks.

Each phase pays for itself. And you can stop after any phase—partial zero trust is infinitely better than none.

The Bottom Line for the CFO

Zero trust is not a buzzword. It is insurance against the single biggest operational risk most companies face: a breach that spreads because there were no internal barriers. The ZTNA ROI is not theoretical—it shows up in every breach post-mortem I have read and every incident I have responded to.

You insure against the risks that take down the business. Zero trust is that insurance, deployed at a fraction of the cost of the incident it prevents.

And if you need a line item for the board: ₹25-40 lakh for a 200-person company, versus ₹12-20 crore for the breach it prevents. The math is on your side.

Sanjay Seth has been designing network architectures since 1992. He has helped deploy zero-trust environments across manufacturing, healthcare, finance, and government sectors in India. If your CFO is still asking “why,” send them this article.

The post Zero-Trust Without the Buzzword — Explaining It to a CFO appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

But I have told clients not to buy Fortinet. More than once. And I will do it again.

Here is when.

When Your Team Has Deep Palo Alto Experience

I have seen this play out too many times: a CISO arrives from an organisation that ran Palo Alto. They join a new company considering Fortinet. The logical choice on paper turns into a training nightmare because the team has 15 years of PAN-OS muscle memory.

The firewall is only as good as the team managing it. If your team knows Palo Alto cold and FortiGate warm, you are better off buying Palo Alto—even if it costs more per Mbps. I have seen an enterprise spend ₹18 lakh on FortiGates and then burn ₹25 lakh in overtime while the team struggled to migrate rulebases. This is a common FortiGate vs Palo Alto dynamic: hardware benchmarks favour Fortinet, operational familiarity favours Palo Alto. Pick the one your team can operate at 3 AM.

When You Need a Truly Multi-Vendor Strategy and Cannot Pick One

Some enterprises—especially very large banks and telecoms—have legitimate reasons to run multiple firewall vendors. Acquisitions bring inherited estates. Regional compliance requirements mandate specific vendors. Geopolitical supply chain concerns make single-vendor dependency a risk. If your architecture genuinely requires three vendors, do not let a partner talk you into standardising on one before you are ready.

But be honest: is it a genuine requirement, or is it “we have always done it this way”? I have seen data centres running three firewall vendors because nobody had the courage to standardise. That triples the training load, management platform cost, and surface area for configuration drift. If you need Fortinet alternatives in specific regions, run those through a proper TCO analysis first.

When You Are Buying Firewalls Without a Managed Service

A FortiGate 600F sitting in a rack with default settings, unpatched firmware, and no active monitoring is not security. It is a very expensive paperweight. If your organisation does not have the team to configure, tune, monitor, and maintain a Fortinet deployment, buying it is worse than buying nothing—because you will have a false sense of security that will not survive its first real test. I have seen this exact scenario: a mid-market company bought two 400F units, deployed them with a default permit-all rule structure, and never touched them again. When a ransomware incident hit six months later, the firewall had logged the C2 beacon traffic—but nobody had looked at the logs because there was no monitoring, no SIEM integration, no rule review cadence.

My honest advice in this scenario: either build the team first (hire a senior Fortinet engineer, budget for FortiManager, plan the training programme), or buy a managed service from someone who already has the team. Do not buy the hardware and hope the expertise materialises. This is not a knock against Fortinet. It applies equally to every firewall vendor on the market.

When You Want a “Set and Forget” Firewall

No firewall is set-and-forget. Not Fortinet. Not Palo Alto. Not Cisco. Not anyone. But some vendors do a better job of surfacing what needs attention in a way that matches your team’s skill level. If your team does not have the bandwidth to manage a security relationship with the vendor—quarterly firmware updates, monthly rule reviews, weekly threat feed tuning, SSL certificate lifecycle management—Fortinet’s ecosystem will not save you.

In that case, I would recommend a fully managed firewall service rather than a product purchase. The product is not the solution. The operations around the product are the solution. An MSSP recommendation that leads with “buy this hardware” without checking your operational readiness is not a recommendation—it is a sales pitch. I avoid those.

When Your Compliance Requirements Favour a Different Ecosystem

Certain regulated industries have compliance frameworks that map more cleanly to specific vendors. Healthcare organisations in the US often prefer Palo Alto for its HIPAA compliance documentation. Indian banks with their specific CERT-In reporting requirements sometimes find that a particular vendor’s logging and reporting module maps better to the audit framework. If your compliance auditor has strong opinions about which vendor makes their job easier, that is a real factor. Do not ignore it because of a price advantage on hardware.

I have told clients: “Fortinet can meet these requirements, but it will take more config work. Palo Alto has a pre-built compliance dashboard. You will pay more per unit but spend less time in audit.” Some chose Fortinet and made it work. Some switched. Both were right for their context.

When Budget Is the Only Reason You Are Choosing Fortinet

Fortinet is cheaper per Mbps than Palo Alto. But if the only reason is price, you have not done the full analysis. TCO includes training, management licensing, support contracts, and the cost of a less familiar interface during a crisis. I have seen procurement teams claim “Fortinet is 40% cheaper” without accounting for FortiManager, FortiAnalyzer, FortiCare, and training. The real gap was closer to 15%.

The Honest Truth

I am a Fortinet partner because I genuinely believe their hardware is the best price-to-performance in the market. I have deployed over a thousand of them. I know what they do well (a lot) and where they have gaps (a few—every vendor has them). When I make an honest firewall advice recommendation, I start with the team, the operations, and the compliance requirements—and only then look at the hardware.

But the best firewall for you is the one your team can manage effectively, consistently, and securely. If that is Fortinet, great—I will help you get the most out of it. If it is Palo Alto, I will help you get the most out of that too. If it is Sophos, I will raise an eyebrow and then help you make it work.

Trust in cybersecurity is built on honesty. And the most honest thing I can say is: I would rather you buy the right firewall from someone else than the wrong firewall from me.

Sanjay Seth, CEO of P J Networks. We are a Fortinet MSSP partner, but we have deployed and managed every major firewall brand. If you want an honest conversation about what fits your environment, talk to us.

The post When I Tell Clients NOT to Buy Fortinet appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

But I have told clients not to buy Fortinet. More than once. And I will do it again.

Here is when.

When Your Team Has Deep Palo Alto Experience

I have seen this play out too many times: a CISO arrives from an organisation that ran Palo Alto. They join a new company considering Fortinet. The logical choice on paper turns into a training nightmare because the team has 15 years of PAN-OS muscle memory.

The firewall is only as good as the team managing it. If your team knows Palo Alto cold and FortiGate warm, you are better off buying Palo Alto—even if it costs more per Mbps. I have seen an enterprise spend ₹18 lakh on FortiGates and then burn ₹25 lakh in overtime while the team struggled to migrate rulebases. This is a common FortiGate vs Palo Alto dynamic: hardware benchmarks favour Fortinet, operational familiarity favours Palo Alto. Pick the one your team can operate at 3 AM.

When You Need a Truly Multi-Vendor Strategy and Cannot Pick One

Some enterprises—especially very large banks and telecoms—have legitimate reasons to run multiple firewall vendors. Acquisitions bring inherited estates. Regional compliance requirements mandate specific vendors. Geopolitical supply chain concerns make single-vendor dependency a risk. If your architecture genuinely requires three vendors, do not let a partner talk you into standardising on one before you are ready.

But be honest: is it a genuine requirement, or is it “we have always done it this way”? I have seen data centres running three firewall vendors because nobody had the courage to standardise. That triples the training load, management platform cost, and surface area for configuration drift. If you need Fortinet alternatives in specific regions, run those through a proper TCO analysis first.

When You Are Buying Firewalls Without a Managed Service

A FortiGate 600F sitting in a rack with default settings, unpatched firmware, and no active monitoring is not security. It is a very expensive paperweight. If your organisation does not have the team to configure, tune, monitor, and maintain a Fortinet deployment, buying it is worse than buying nothing—because you will have a false sense of security that will not survive its first real test. I have seen this exact scenario: a mid-market company bought two 400F units, deployed them with a default permit-all rule structure, and never touched them again. When a ransomware incident hit six months later, the firewall had logged the C2 beacon traffic—but nobody had looked at the logs because there was no monitoring, no SIEM integration, no rule review cadence.

My honest advice in this scenario: either build the team first (hire a senior Fortinet engineer, budget for FortiManager, plan the training programme), or buy a managed service from someone who already has the team. Do not buy the hardware and hope the expertise materialises. This is not a knock against Fortinet. It applies equally to every firewall vendor on the market.

When You Want a “Set and Forget” Firewall

No firewall is set-and-forget. Not Fortinet. Not Palo Alto. Not Cisco. Not anyone. But some vendors do a better job of surfacing what needs attention in a way that matches your team’s skill level. If your team does not have the bandwidth to manage a security relationship with the vendor—quarterly firmware updates, monthly rule reviews, weekly threat feed tuning, SSL certificate lifecycle management—Fortinet’s ecosystem will not save you.

In that case, I would recommend a fully managed firewall service rather than a product purchase. The product is not the solution. The operations around the product are the solution. An MSSP recommendation that leads with “buy this hardware” without checking your operational readiness is not a recommendation—it is a sales pitch. I avoid those.

When Your Compliance Requirements Favour a Different Ecosystem

Certain regulated industries have compliance frameworks that map more cleanly to specific vendors. Healthcare organisations in the US often prefer Palo Alto for its HIPAA compliance documentation. Indian banks with their specific CERT-In reporting requirements sometimes find that a particular vendor’s logging and reporting module maps better to the audit framework. If your compliance auditor has strong opinions about which vendor makes their job easier, that is a real factor. Do not ignore it because of a price advantage on hardware.

I have told clients: “Fortinet can meet these requirements, but it will take more config work. Palo Alto has a pre-built compliance dashboard. You will pay more per unit but spend less time in audit.” Some chose Fortinet and made it work. Some switched. Both were right for their context.

When Budget Is the Only Reason You Are Choosing Fortinet

Fortinet is cheaper per Mbps than Palo Alto. But if the only reason is price, you have not done the full analysis. TCO includes training, management licensing, support contracts, and the cost of a less familiar interface during a crisis. I have seen procurement teams claim “Fortinet is 40% cheaper” without accounting for FortiManager, FortiAnalyzer, FortiCare, and training. The real gap was closer to 15%.

The Honest Truth

I am a Fortinet partner because I genuinely believe their hardware is the best price-to-performance in the market. I have deployed over a thousand of them. I know what they do well (a lot) and where they have gaps (a few—every vendor has them). When I make an honest firewall advice recommendation, I start with the team, the operations, and the compliance requirements—and only then look at the hardware.

But the best firewall for you is the one your team can manage effectively, consistently, and securely. If that is Fortinet, great—I will help you get the most out of it. If it is Palo Alto, I will help you get the most out of that too. If it is Sophos, I will raise an eyebrow and then help you make it work.

Trust in cybersecurity is built on honesty. And the most honest thing I can say is: I would rather you buy the right firewall from someone else than the wrong firewall from me.

Sanjay Seth, CEO of P J Networks. We are a Fortinet MSSP partner, but we have deployed and managed every major firewall brand. If you want an honest conversation about what fits your environment, talk to us.

The post When I Tell Clients NOT to Buy Fortinet appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

But I have told clients not to buy Fortinet. More than once. And I will do it again.

Here is when.

When Your Team Has Deep Palo Alto Experience

I have seen this play out too many times: a CISO arrives from an organisation that ran Palo Alto. They join a new company considering Fortinet. The logical choice on paper turns into a training nightmare because the team has 15 years of PAN-OS muscle memory.

The firewall is only as good as the team managing it. If your team knows Palo Alto cold and FortiGate warm, you are better off buying Palo Alto—even if it costs more per Mbps. I have seen an enterprise spend ₹18 lakh on FortiGates and then burn ₹25 lakh in overtime while the team struggled to migrate rulebases. This is a common FortiGate vs Palo Alto dynamic: hardware benchmarks favour Fortinet, operational familiarity favours Palo Alto. Pick the one your team can operate at 3 AM.

When You Need a Truly Multi-Vendor Strategy and Cannot Pick One

Some enterprises—especially very large banks and telecoms—have legitimate reasons to run multiple firewall vendors. Acquisitions bring inherited estates. Regional compliance requirements mandate specific vendors. Geopolitical supply chain concerns make single-vendor dependency a risk. If your architecture genuinely requires three vendors, do not let a partner talk you into standardising on one before you are ready.

But be honest: is it a genuine requirement, or is it “we have always done it this way”? I have seen data centres running three firewall vendors because nobody had the courage to standardise. That triples the training load, management platform cost, and surface area for configuration drift. If you need Fortinet alternatives in specific regions, run those through a proper TCO analysis first.

When You Are Buying Firewalls Without a Managed Service

A FortiGate 600F sitting in a rack with default settings, unpatched firmware, and no active monitoring is not security. It is a very expensive paperweight. If your organisation does not have the team to configure, tune, monitor, and maintain a Fortinet deployment, buying it is worse than buying nothing—because you will have a false sense of security that will not survive its first real test. I have seen this exact scenario: a mid-market company bought two 400F units, deployed them with a default permit-all rule structure, and never touched them again. When a ransomware incident hit six months later, the firewall had logged the C2 beacon traffic—but nobody had looked at the logs because there was no monitoring, no SIEM integration, no rule review cadence.

My honest advice in this scenario: either build the team first (hire a senior Fortinet engineer, budget for FortiManager, plan the training programme), or buy a managed service from someone who already has the team. Do not buy the hardware and hope the expertise materialises. This is not a knock against Fortinet. It applies equally to every firewall vendor on the market.

When You Want a “Set and Forget” Firewall

No firewall is set-and-forget. Not Fortinet. Not Palo Alto. Not Cisco. Not anyone. But some vendors do a better job of surfacing what needs attention in a way that matches your team’s skill level. If your team does not have the bandwidth to manage a security relationship with the vendor—quarterly firmware updates, monthly rule reviews, weekly threat feed tuning, SSL certificate lifecycle management—Fortinet’s ecosystem will not save you.

In that case, I would recommend a fully managed firewall service rather than a product purchase. The product is not the solution. The operations around the product are the solution. An MSSP recommendation that leads with “buy this hardware” without checking your operational readiness is not a recommendation—it is a sales pitch. I avoid those.

When Your Compliance Requirements Favour a Different Ecosystem

Certain regulated industries have compliance frameworks that map more cleanly to specific vendors. Healthcare organisations in the US often prefer Palo Alto for its HIPAA compliance documentation. Indian banks with their specific CERT-In reporting requirements sometimes find that a particular vendor’s logging and reporting module maps better to the audit framework. If your compliance auditor has strong opinions about which vendor makes their job easier, that is a real factor. Do not ignore it because of a price advantage on hardware.

I have told clients: “Fortinet can meet these requirements, but it will take more config work. Palo Alto has a pre-built compliance dashboard. You will pay more per unit but spend less time in audit.” Some chose Fortinet and made it work. Some switched. Both were right for their context.

When Budget Is the Only Reason You Are Choosing Fortinet

Fortinet is cheaper per Mbps than Palo Alto. But if the only reason is price, you have not done the full analysis. TCO includes training, management licensing, support contracts, and the cost of a less familiar interface during a crisis. I have seen procurement teams claim “Fortinet is 40% cheaper” without accounting for FortiManager, FortiAnalyzer, FortiCare, and training. The real gap was closer to 15%.

The Honest Truth

I am a Fortinet partner because I genuinely believe their hardware is the best price-to-performance in the market. I have deployed over a thousand of them. I know what they do well (a lot) and where they have gaps (a few—every vendor has them). When I make an honest firewall advice recommendation, I start with the team, the operations, and the compliance requirements—and only then look at the hardware.

But the best firewall for you is the one your team can manage effectively, consistently, and securely. If that is Fortinet, great—I will help you get the most out of it. If it is Palo Alto, I will help you get the most out of that too. If it is Sophos, I will raise an eyebrow and then help you make it work.

Trust in cybersecurity is built on honesty. And the most honest thing I can say is: I would rather you buy the right firewall from someone else than the wrong firewall from me.

Sanjay Seth, CEO of P J Networks. We are a Fortinet MSSP partner, but we have deployed and managed every major firewall brand. If you want an honest conversation about what fits your environment, talk to us.

The post When I Tell Clients NOT to Buy Fortinet appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

But I have told clients not to buy Fortinet. More than once. And I will do it again.

Here is when.

When Your Team Has Deep Palo Alto Experience

I have seen this play out too many times: a CISO arrives from an organisation that ran Palo Alto. They join a new company considering Fortinet. The logical choice on paper turns into a training nightmare because the team has 15 years of PAN-OS muscle memory.

The firewall is only as good as the team managing it. If your team knows Palo Alto cold and FortiGate warm, you are better off buying Palo Alto—even if it costs more per Mbps. I have seen an enterprise spend ₹18 lakh on FortiGates and then burn ₹25 lakh in overtime while the team struggled to migrate rulebases. This is a common FortiGate vs Palo Alto dynamic: hardware benchmarks favour Fortinet, operational familiarity favours Palo Alto. Pick the one your team can operate at 3 AM.

When You Need a Truly Multi-Vendor Strategy and Cannot Pick One

Some enterprises—especially very large banks and telecoms—have legitimate reasons to run multiple firewall vendors. Acquisitions bring inherited estates. Regional compliance requirements mandate specific vendors. Geopolitical supply chain concerns make single-vendor dependency a risk. If your architecture genuinely requires three vendors, do not let a partner talk you into standardising on one before you are ready.

But be honest: is it a genuine requirement, or is it “we have always done it this way”? I have seen data centres running three firewall vendors because nobody had the courage to standardise. That triples the training load, management platform cost, and surface area for configuration drift. If you need Fortinet alternatives in specific regions, run those through a proper TCO analysis first.

When You Are Buying Firewalls Without a Managed Service

A FortiGate 600F sitting in a rack with default settings, unpatched firmware, and no active monitoring is not security. It is a very expensive paperweight. If your organisation does not have the team to configure, tune, monitor, and maintain a Fortinet deployment, buying it is worse than buying nothing—because you will have a false sense of security that will not survive its first real test. I have seen this exact scenario: a mid-market company bought two 400F units, deployed them with a default permit-all rule structure, and never touched them again. When a ransomware incident hit six months later, the firewall had logged the C2 beacon traffic—but nobody had looked at the logs because there was no monitoring, no SIEM integration, no rule review cadence.

My honest advice in this scenario: either build the team first (hire a senior Fortinet engineer, budget for FortiManager, plan the training programme), or buy a managed service from someone who already has the team. Do not buy the hardware and hope the expertise materialises. This is not a knock against Fortinet. It applies equally to every firewall vendor on the market.

When You Want a “Set and Forget” Firewall

No firewall is set-and-forget. Not Fortinet. Not Palo Alto. Not Cisco. Not anyone. But some vendors do a better job of surfacing what needs attention in a way that matches your team’s skill level. If your team does not have the bandwidth to manage a security relationship with the vendor—quarterly firmware updates, monthly rule reviews, weekly threat feed tuning, SSL certificate lifecycle management—Fortinet’s ecosystem will not save you.

In that case, I would recommend a fully managed firewall service rather than a product purchase. The product is not the solution. The operations around the product are the solution. An MSSP recommendation that leads with “buy this hardware” without checking your operational readiness is not a recommendation—it is a sales pitch. I avoid those.

When Your Compliance Requirements Favour a Different Ecosystem

Certain regulated industries have compliance frameworks that map more cleanly to specific vendors. Healthcare organisations in the US often prefer Palo Alto for its HIPAA compliance documentation. Indian banks with their specific CERT-In reporting requirements sometimes find that a particular vendor’s logging and reporting module maps better to the audit framework. If your compliance auditor has strong opinions about which vendor makes their job easier, that is a real factor. Do not ignore it because of a price advantage on hardware.

I have told clients: “Fortinet can meet these requirements, but it will take more config work. Palo Alto has a pre-built compliance dashboard. You will pay more per unit but spend less time in audit.” Some chose Fortinet and made it work. Some switched. Both were right for their context.

When Budget Is the Only Reason You Are Choosing Fortinet

Fortinet is cheaper per Mbps than Palo Alto. But if the only reason is price, you have not done the full analysis. TCO includes training, management licensing, support contracts, and the cost of a less familiar interface during a crisis. I have seen procurement teams claim “Fortinet is 40% cheaper” without accounting for FortiManager, FortiAnalyzer, FortiCare, and training. The real gap was closer to 15%.

The Honest Truth

I am a Fortinet partner because I genuinely believe their hardware is the best price-to-performance in the market. I have deployed over a thousand of them. I know what they do well (a lot) and where they have gaps (a few—every vendor has them). When I make an honest firewall advice recommendation, I start with the team, the operations, and the compliance requirements—and only then look at the hardware.

But the best firewall for you is the one your team can manage effectively, consistently, and securely. If that is Fortinet, great—I will help you get the most out of it. If it is Palo Alto, I will help you get the most out of that too. If it is Sophos, I will raise an eyebrow and then help you make it work.

Trust in cybersecurity is built on honesty. And the most honest thing I can say is: I would rather you buy the right firewall from someone else than the wrong firewall from me.

Sanjay Seth, CEO of P J Networks. We are a Fortinet MSSP partner, but we have deployed and managed every major firewall brand. If you want an honest conversation about what fits your environment, talk to us.

The post When I Tell Clients NOT to Buy Fortinet appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

But I have told clients not to buy Fortinet. More than once. And I will do it again.

Here is when.

When Your Team Has Deep Palo Alto Experience

I have seen this play out too many times: a CISO arrives from an organisation that ran Palo Alto. They join a new company considering Fortinet. The logical choice on paper turns into a training nightmare because the team has 15 years of PAN-OS muscle memory.

The firewall is only as good as the team managing it. If your team knows Palo Alto cold and FortiGate warm, you are better off buying Palo Alto—even if it costs more per Mbps. I have seen an enterprise spend ₹18 lakh on FortiGates and then burn ₹25 lakh in overtime while the team struggled to migrate rulebases. This is a common FortiGate vs Palo Alto dynamic: hardware benchmarks favour Fortinet, operational familiarity favours Palo Alto. Pick the one your team can operate at 3 AM.

When You Need a Truly Multi-Vendor Strategy and Cannot Pick One

Some enterprises—especially very large banks and telecoms—have legitimate reasons to run multiple firewall vendors. Acquisitions bring inherited estates. Regional compliance requirements mandate specific vendors. Geopolitical supply chain concerns make single-vendor dependency a risk. If your architecture genuinely requires three vendors, do not let a partner talk you into standardising on one before you are ready.

But be honest: is it a genuine requirement, or is it “we have always done it this way”? I have seen data centres running three firewall vendors because nobody had the courage to standardise. That triples the training load, management platform cost, and surface area for configuration drift. If you need Fortinet alternatives in specific regions, run those through a proper TCO analysis first.

When You Are Buying Firewalls Without a Managed Service

A FortiGate 600F sitting in a rack with default settings, unpatched firmware, and no active monitoring is not security. It is a very expensive paperweight. If your organisation does not have the team to configure, tune, monitor, and maintain a Fortinet deployment, buying it is worse than buying nothing—because you will have a false sense of security that will not survive its first real test. I have seen this exact scenario: a mid-market company bought two 400F units, deployed them with a default permit-all rule structure, and never touched them again. When a ransomware incident hit six months later, the firewall had logged the C2 beacon traffic—but nobody had looked at the logs because there was no monitoring, no SIEM integration, no rule review cadence.

My honest advice in this scenario: either build the team first (hire a senior Fortinet engineer, budget for FortiManager, plan the training programme), or buy a managed service from someone who already has the team. Do not buy the hardware and hope the expertise materialises. This is not a knock against Fortinet. It applies equally to every firewall vendor on the market.

When You Want a “Set and Forget” Firewall

No firewall is set-and-forget. Not Fortinet. Not Palo Alto. Not Cisco. Not anyone. But some vendors do a better job of surfacing what needs attention in a way that matches your team’s skill level. If your team does not have the bandwidth to manage a security relationship with the vendor—quarterly firmware updates, monthly rule reviews, weekly threat feed tuning, SSL certificate lifecycle management—Fortinet’s ecosystem will not save you.

In that case, I would recommend a fully managed firewall service rather than a product purchase. The product is not the solution. The operations around the product are the solution. An MSSP recommendation that leads with “buy this hardware” without checking your operational readiness is not a recommendation—it is a sales pitch. I avoid those.

When Your Compliance Requirements Favour a Different Ecosystem

Certain regulated industries have compliance frameworks that map more cleanly to specific vendors. Healthcare organisations in the US often prefer Palo Alto for its HIPAA compliance documentation. Indian banks with their specific CERT-In reporting requirements sometimes find that a particular vendor’s logging and reporting module maps better to the audit framework. If your compliance auditor has strong opinions about which vendor makes their job easier, that is a real factor. Do not ignore it because of a price advantage on hardware.

I have told clients: “Fortinet can meet these requirements, but it will take more config work. Palo Alto has a pre-built compliance dashboard. You will pay more per unit but spend less time in audit.” Some chose Fortinet and made it work. Some switched. Both were right for their context.

When Budget Is the Only Reason You Are Choosing Fortinet

Fortinet is cheaper per Mbps than Palo Alto. But if the only reason is price, you have not done the full analysis. TCO includes training, management licensing, support contracts, and the cost of a less familiar interface during a crisis. I have seen procurement teams claim “Fortinet is 40% cheaper” without accounting for FortiManager, FortiAnalyzer, FortiCare, and training. The real gap was closer to 15%.

The Honest Truth

I am a Fortinet partner because I genuinely believe their hardware is the best price-to-performance in the market. I have deployed over a thousand of them. I know what they do well (a lot) and where they have gaps (a few—every vendor has them). When I make an honest firewall advice recommendation, I start with the team, the operations, and the compliance requirements—and only then look at the hardware.

But the best firewall for you is the one your team can manage effectively, consistently, and securely. If that is Fortinet, great—I will help you get the most out of it. If it is Palo Alto, I will help you get the most out of that too. If it is Sophos, I will raise an eyebrow and then help you make it work.

Trust in cybersecurity is built on honesty. And the most honest thing I can say is: I would rather you buy the right firewall from someone else than the wrong firewall from me.

Sanjay Seth, CEO of P J Networks. We are a Fortinet MSSP partner, but we have deployed and managed every major firewall brand. If you want an honest conversation about what fits your environment, talk to us.

The post When I Tell Clients NOT to Buy Fortinet appeared first on Sanjay Seth — Cybersecurity & Network Consultant.