How to Manage Network Switches When Your Firewall is controlled by an MSP

Published: September 8, 2026 | Last Technically Reviewed: September 8, 2026

Quick Answer

If your firewall is controlled by an MSP but your internal IT team owns the LAN, do not assume the switches should use the firewall as their management plane. The safer starting point is to evaluate a switch architecture that gives internal IT direct control of switch configuration, administrator permissions, firmware, logs, backups and future 802.1X operations. With FortiSwitch, current Fortinet documentation supports standalone local management, FortiGate/FortiLink management and cloud management of standalone switches through FortiEdge Cloud, so firewall integration is an option rather than an absolute requirement. Before purchasing hundreds of switches, validate who owns the management tenant, licensing, emergency access and configuration exports-and test how one switch behaves when the firewall, cloud platform or MSP relationship is unavailable or changed.

Introduction

A network team can own hundreds of switches without owning the firewall in front of them.

That sounds like an organizational detail. In practice, it can completely change which managed network switch architecture makes sense.

The question is not hypothetical.

A recent public r/networking discussion involved an administrator planning a LAN refresh across roughly 50 sites and more than 300 switches. The immediate requirements were mostly Layer 2: PoE, VLANs, centralized visibility, multiple administrators and possible future 802.1X. After another participant suggested FortiSwitch because the existing WAN edge used Fortinet, the original poster raised the critical operational constraint: the WAN edge was fully managed by a third party, while the internal team needed to retain LAN responsibility.

Original Reddit thread: "Budget" LAN Refresh - HPE Instant On

The research behind this article treats that discussion as a public enterprise networking case, not a Network-Switch.com customer inquiry. The underlying research explicitly separates public community users from verified company customers and treats community replies as problem evidence rather than vendor specification.

Quick Answer: Network switches can often be managed separately from the firewall, but the answer depends on the management architecture rather than simply the switch brand. Fortinet currently supports standalone FortiSwitch management through local GUI/CLI, FortiGate-managed switching through FortiLink, and centralized cloud management of standalone FortiSwitches through FortiEdge Cloud. When the firewall belongs to an MSP but internal IT owns the LAN, the management tenant, administrator rights, firmware, licensing, logs, 802.1X and exit path should be decided before the switches are purchased.

Why Switch Price Is Only Part of a Multi-Site LAN Refresh

For a single access switch, comparing hardware prices is straightforward.

For 300 switches spread across dozens of sites, the unit price is only one part of the cost.

The operational equation is closer to:

**Hardware

• Deployment labor
• Configuration consistency
• Firmware lifecycle
• Monitoring
• Audit
• Administrator permissions
  + 802.1X rollout
• Troubleshooting time
  = Operational cost**

A lower-priced switch can become expensive if every site has to be configured, upgraded and investigated individually.

That does not mean cloud management is always cheaper.

It means procurement should reflect the actual operating model.

In multi-site BOM and architecture reviews, this is one of the requirements I would want defined before narrowing the SKU list. A switch can meet every visible hardware requirement-24 ports, PoE+, VLAN support and 10G uplinks-and still be the wrong platform if the organization responsible for the LAN cannot control its management plane.

The Reddit case makes that problem concrete. The original poster was evaluating a low-cost refresh and specifically wanted cloud visibility, auditability and future 802.1X. A participant suggested FortiSwitch because of the existing Fortinet environment, but the poster then explained that the firewall environment was not under the internal team's control.

That changed the question from:

Which switch is cheaper?

to:

Which management architecture lets the internal team operate the LAN without depending on the MSP for every switch-level action?

Centralized management is valuable only when the right team controls it.

Can Switches Be Managed Independently of the Firewall?

For FortiSwitch, the answer is clearly yes-but not in every management mode at the same time.

Fortinet's current FortiSwitchOS 8.0.0 Administration Guide explicitly states that in standalone mode, a FortiSwitch is managed directly through its local Web GUI or CLI. The same guide separately points administrators to FortiGate/FortiLink, FortiEdge Cloud and FortiSwitch Manager when those management architectures are used.

Fortinet: FortiSwitchOS 8.0.0 - Standalone Management Introduction

Fortinet also describes FortiEdge Cloud 26.2 as a centralized management platform for standalone FortiSwitch, FortiAP and FortiExtender deployments, with support for multiple sites and large numbers of devices.

Fortinet: FortiEdge Cloud 26.2 Documentation

That means an MSP-managed FortiGate does not automatically force the organization's switches into FortiGate-controlled management.

But the management model must be chosen deliberately.

Management Architecture Comparison

The final row is especially important.

Fortinet's current FortiManager documentation says FortiSwitch Manager manages FortiSwitches controlled by FortiGate devices that are themselves managed by FortiManager. It explicitly states that a standalone FortiSwitch cannot simply be added directly to FortiManager.

Fortinet: FortiSwitch Manager in FortiManager 7.6.6

There is another detail that matters for a proposed "hybrid" design.

Fortinet's current zero-touch management documentation states that only one manager can be used at a time in most cases. A switch may discover different possible managers, but that does not mean FortiGate, FortiEdge Cloud and another controller should all be treated as simultaneous authoritative configuration systems.

Fortinet: FortiSwitch Zero-Touch Management and Manager Selection

So the practical principle is:

"Supported by the same vendor" does not mean "must be managed by the same team."

It also does not mean:

"Every available manager can control the switch simultaneously."

What Changes When the Firewall Is Controlled by an MSP?

Consider the ownership boundary first:

Third-Party MSP
 Firewall / WAN Edge
     WAN
     Internet
     SD-WAN
     Security Policy

Internal IT
 LAN
     Access Switches
     VLANs
     PoE
     APs
     Phones
     Cameras
     User Ports

Technically, those systems can still integrate.

Operationally, however, the ownership boundary matters.

Suppose internal IT needs to move a user to another VLAN.

Can it do so without opening an MSP ticket?

Suppose an AP loses PoE.

Can internal IT inspect the switch port, check the power state and cycle PoE?

Suppose an emergency firmware advisory affects the access layer.

Who owns the maintenance window?

Suppose the MSP contract ends.

Who owns the switch configuration?

Those questions are part of the network architecture.

They are not paperwork that should be solved after deployment.

This leads to one of the main conclusions of the article:

Technical integration and administrative ownership are two different design decisions.

An integrated firewall-switch design can be technically elegant and still be operationally wrong if the organizations responsible for the two layers are different.

This does not mean integrated management should automatically be rejected.

If the MSP can provide appropriately scoped access, the customer owns the relevant assets and accounts, audit visibility exists, and operational responsibilities are contractually clear, integration may still be appropriate.

But those conditions should be demonstrated-not assumed.

Who Owns Configuration, Licensing, Logs and 802.1X?

Instead of filling every row with "Depends," I would start with a default responsibility model and then change it when the actual contract or architecture requires something different.

Recommended Starting Responsibility Model

This is an engineering starting point, not an industry mandate.

Projects may legitimately assign the rows differently.

The useful change is that ownership is explicit before purchase.

Future 802.1X Makes the Boundary More Important

The original public project specifically mentioned possible future 802.1X, which is one reason management ownership should not be designed only around today's VLAN and PoE requirements.

Fortinet's standalone FortiSwitch documentation confirms that FortiSwitchOS supports 802.1X directly with a RADIUS server.

Fortinet: FortiSwitchOS 7.6.5 Port Security and 802.1X

In FortiLink-managed deployments, Fortinet documents an additional dependency: if the managed FortiSwitch must reach a RADIUS server through the FortiGate, an appropriate FortiGate firewall policy is required for that RADIUS traffic.

Fortinet: FortiSwitch Security Policies and 802.1X in FortiLink Mode

That produces a practical ownership chain:

Endpoint
   
Switch
   
RADIUS / Identity
   
Access Decision

If RADIUS traffic crosses the MSP firewall:
   
MSP Firewall Policy

Before purchasing the switch platform, I would therefore ask:

• Who owns the RADIUS or identity platform?
• Who pushes 802.1X configuration?
• Who sees failed-authentication events?
• Who creates temporary exceptions?
• Who changes the auth-fail or server-timeout behavior?
• Can internal IT troubleshoot a user without full firewall access?
• Can an MSP firewall-policy change unintentionally break RADIUS reachability?

A switch that is easy to manage today may become difficult once identity becomes part of the access path.

What Still Works if the Firewall or Management Platform Goes Down?

This is where the article needs to be especially precise.

There are at least four different availability questions:

Forwarding availability
Authentication availability
Configuration availability
Management visibility

Do not reduce all four to "Does the cloud work?"

Forwarding

Ask whether existing:

• Layer 2 forwarding;
• VLANs;
• trunks;
• PoE;
• MAC learning

continue when the management platform is unavailable.

For FortiLink-managed FortiSwitches, Fortinet documents that the active FortiLink carries both data and management traffic, and that the FortiGate uses the active FortiLink to manage downstream switches.

Fortinet: FortiLink Network Topology and Management Path

But that statement alone does not provide a blanket answer for every forwarding state during every possible FortiGate outage.

I would not turn the documentation into a guarantee it does not make.

That behavior belongs in the pilot test.

Authentication

Test separately:

• existing authenticated sessions;
• new 802.1X sessions;
• MAB clients;
• RADIUS failure;
• auth-server-timeout VLAN behavior;
• reauthentication after RADIUS loss.

FortiSwitch standalone documentation specifically provides authentication-server timeout behavior, including a timeout VLAN option.

That is much more useful than assuming "802.1X fails completely if RADIUS goes down."

Configuration

Ask whether internal IT can still:

• change VLAN membership;
• bounce a port;
• cycle PoE;
• inspect counters;
• log in locally;
• apply an emergency configuration.

Standalone FortiSwitch explicitly supports direct GUI/CLI management.

For FortiLink mode, Fortinet warns administrators to use FortiGate as the management authority unless documentation specifically instructs direct configuration; unmanaged local changes may not be synchronized correctly.

That distinction matters considerably when designing a break-glass procedure.

Visibility

Finally, determine what diagnostic data remain available:

• interface counters;
• MAC table;
• PoE state;
• LLDP;
• local logs;
• 802.1X sessions;
• RADIUS failures.

FortiEdge Cloud provides centralized FortiSwitch monitoring including MAC addresses, switch/port statistics, PoE, LLDP and 802.1X information.

Fortinet: Managing and Monitoring FortiSwitch With FortiEdge Cloud

Fortinet also maintains a service-status mechanism for FortiEdge Cloud GUI and REST API outages.

That tells us the management service itself can experience incidents.

It does not, by itself, define every switch forwarding and authentication behavior during such an incident.

Again:

test the failure mode instead of inferring it from the product name.

How to Evaluate the Management Architecture Before Buying Hundreds of Switches

The pilot should validate more than VLAN creation and PoE.

Pre-Purchase Decision Matrix

Pre-Purchase Management Checklist

Ownership

• Who owns the firewall?
• Who owns the switches?
• Who owns the FortiCloud/FortiEdge account?
• Who retains the assets if the MSP changes?

Administration

• Can internal IT administer switches without firewall-admin rights?
• Are permissions sufficiently granular?
• Is there a break-glass account?
• Can actions be audited?

Licensing

• Who owns the entitlement?
• Who receives renewal notifications?
• Can licensing remain with the customer after MSP termination?

Configuration

• Which manager is authoritative?
• Is standalone management available?
• Can configurations be exported?
• What happens when the management mode changes?

Visibility

• Can internal IT see switch topology?
• Can it inspect PoE?
• Can it see 802.1X failures?
• Can logs be exported independently?

Failure Tests

• Disconnect cloud access.
• Interrupt RADIUS.
• Test firewall/controller loss.
• Verify local troubleshooting.
• Verify existing forwarding.
• Verify new authentication.

Exit Plan

• Move one test switch out of the current management architecture.
• Restore it using customer-held records.
• Verify how long the process takes.
• Document which settings survive and which must be rebuilt.

Fortinet's current 8.0 FortiLink documentation is particularly relevant here: a non-default standalone switch that is being prepared for FortiGate management may need to be reset, and the switch reboots into FortiLink mode after authorization.

That is exactly the kind of behavior a 300-switch project should understand before rollout.

The procurement rule I would use is simple:

Before buying 300 switches, test the exit path for one switch.

The Better Question Is Not "Which Switch Is Cheaper?"

The original Reddit discussion began as a budget LAN-refresh question.

It quickly exposed a more important design issue.

A network with:

• approximately 50 sites;
• more than 300 switches;
• Layer 2 access;
• PoE;
• centralized visibility;
• future 802.1X

looks straightforward until the ownership boundary is added:

the MSP controls the firewall, while internal IT needs to control the LAN.

Verify the original Reddit project and follow-up directly

That single fact can change the preferred management architecture more than a small difference in switch price.

For the projects we review, that is why switch selection should include not only ports, PoE, uplink capacity and compatibility, but also:

• management ownership;
• firmware control;
• identity integration;
• logging;
• licensing;
• outage behavior;
• migration;
• exit planning.

Network-Switch's current engineering review process already evaluates network requirements, switch/PoE capacity, uplinks, management platform fit and BOM compatibility rather than selecting products solely from an isolated SKU specification.

Network-Switch engineering and BOM review

For current product research:

Network-Switch enterprise and managed switch collections

For additional technical articles:

Network-Switch Engineer Lab

Source and Evidence Boundary

This article does not present the Reddit poster as a Network-Switch customer.

The community source is a real, independently accessible r/networking discussion. It establishes the real-world decision context: a large multi-site LAN refresh, centralized-management concerns, future 802.1X and a firewall environment controlled by a third-party provider.

Community replies are used only to show the direction of the discussion.

They are not used as authoritative Fortinet specification.

The technical claims about FortiSwitch management modes, FortiEdge Cloud, FortiSwitch Manager, FortiLink and 802.1X are separately grounded in current Fortinet documentation.

The responsibility matrices, PoC recommendations and exit-plan framework are engineering recommendations from the author-not claims that the Reddit administrator implemented them.

In short:

Community evidence identifies a real problem.
Official documentation establishes product behavior.
Engineering analysis defines what should be validated before purchase.

Official Sources

Public Community Source

Reddit - "Budget" LAN Refresh - HPE Instant On

Fortinet Official Documentation

FortiSwitchOS 8.0.0 - Standalone Management

FortiEdge Cloud 26.2 - Product Documentation

FortiSwitch Manager - FortiManager 7.6.6

FortiSwitch 8.0.0 - Zero-Touch Management and Manager Selection

FortiSwitchOS 7.6.5 - Port Security and Standalone 802.1X

FortiLink 7.6.5 - FortiSwitch Security Policies and 802.1X

FortiSwitch 8.0.0 - Preparing and Authorizing a Switch for FortiLink