When Should Firmware Be Updated at Work?

A firewall that has been running for years without a firmware change may still pass traffic normally. That does not mean it is secure, supported, or prepared for the next vulnerability disclosure. The question of when should firmware be updated is not answered by a calendar reminder alone. It requires balancing security exposure, business uptime, hardware compatibility, and the condition of the existing network.

For a small or midsize business, firmware affects more than a single device. A FortiGate firewall, FortiSwitch, FortiAP, VPN connection, wireless client, and cloud-managed service can all depend on compatible software versions. Updating without a plan can interrupt operations. Waiting too long can leave known flaws exposed or turn a future upgrade into a larger, riskier project.

When Should Firmware Be Updated?

Firmware should be updated when the current version has a security vulnerability, reaches or approaches end of engineering support, causes a documented operational issue, or is required for a planned feature or hardware change. It should also be reviewed routinely as part of lifecycle management, even when nothing appears broken.

The right timing depends on the device and its role. An internet-facing firewall deserves more urgency than a noncritical access point in a low-risk area. A firmware release that addresses an actively exploited vulnerability may require an expedited maintenance window. A feature release that adds functionality your business does not need can wait for normal testing and scheduling.

The goal is not to install every new release on the day it becomes available. The goal is to remain on a supported, stable software path with a documented process for evaluating meaningful changes.

Update promptly for security advisories

A security advisory is the clearest reason to evaluate a firmware update. This is particularly true for perimeter systems such as FortiGate firewalls, remote-access VPN services, wireless controllers, and network management platforms. If a vulnerability allows unauthorized access, remote code execution, privilege escalation, or information disclosure, delaying action can create a direct business risk.

Urgency should be based on the details, not just a severity label. Consider whether the affected feature is enabled, whether the device is internet-facing, whether a workaround exists, and whether there is evidence of active exploitation. Disabling an exposed service or restricting administrative access may reduce risk temporarily, but it is not always a substitute for applying the vendor's corrective release.

For businesses handling payment cards, patient data, legal records, or customer information, a delayed security update can also complicate PCI DSS, HIPAA, contractual, or cyber-insurance obligations. Good patch discipline is evidence that security controls are being maintained, not merely installed.

Update when support is ending

Firmware versions eventually leave standard support. Once that happens, defects may no longer receive fixes, and technical support options can narrow. Staying on an unsupported release because it is familiar often creates a false sense of stability.

This is especially common with firewalls that were installed several years ago and have only received emergency attention. By the time a business needs a new VPN capability, SD-WAN enhancement, or compatibility with a new access point, the firewall may be multiple major versions behind. A simple upgrade can then require staged jumps through interim releases, careful review of configuration changes, and possibly hardware replacement.

Review firmware lifecycle status at least quarterly and include it in annual technology planning. That gives leadership time to budget for a replacement rather than responding under pressure after a failure or vulnerability.

Update to correct a known operational problem

Some updates are justified because the network is showing a specific, repeatable problem. Examples include VPN tunnels dropping after a certain period, unstable wireless roaming, switch ports intermittently renegotiating, excessive firewall memory use, or a cloud management integration failing.

Before treating firmware as the automatic fix, confirm the issue is actually software-related. A failing ISP circuit, a duplex mismatch, a defective cable, an overloaded wireless design, or an incorrect firewall policy will not be reliably solved by updating code. Review logs, interface statistics, event history, and vendor release notes before committing to a change.

If the release notes identify a fix that matches the observed issue, a planned upgrade is often the most efficient remedy. The key is to record the symptoms and verify afterward that the condition has improved.

Do Not Update Firmware Without a Change Plan

A firmware update changes the operating system of network equipment. On a properly managed environment, it should be handled as a controlled change, not an after-hours guess.

Start by confirming the exact model, current version, licensing status, and role of each device. Check the vendor's supported upgrade path rather than assuming a device can jump directly to the latest release. Major version changes may alter default settings, security behavior, SSL inspection handling, VPN compatibility, routing processes, or management features.

Back up configurations before the maintenance window. For a firewall, that means more than exporting the current configuration file. Preserve system settings, policy documentation, VPN details, interface maps, certificates where applicable, and a record of the current firmware image. Verify that the backup can be accessed if a rollback is necessary.

A useful change plan also identifies the expected outage, the people who need notice, the validation steps, and the rollback decision point. For a restaurant, that may mean scheduling after card-processing and ordering activity have stopped. For a medical practice, it may mean avoiding patient hours and confirming that cloud applications, imaging workflows, and secure remote access will be tested before the next business day.

Check dependencies across the network

Firewall, switch, access point, endpoint, and management-platform firmware should not be treated as isolated decisions. A new FortiGate version may require review of FortiSwitch and FortiAP compatibility. A FortiClient update may affect VPN authentication or endpoint telemetry. A change in a wireless platform can affect older printers, scanners, point-of-sale terminals, cameras, and Internet of Things devices.

This does not mean every device must be updated at the same time. It means the versions must be deliberately compatible. In many environments, the firewall is upgraded first, followed by switching and wireless components in a defined sequence. In others, a controller or cloud-managed platform dictates the order.

Documenting these relationships prevents a common mistake: completing a successful firewall upgrade only to discover that a remote office VPN, guest Wi-Fi portal, or access-point management function no longer behaves as expected.

Test business-critical services after the reboot

A device coming back online is not the same as a successful update. After firmware work, validate the services the business actually uses. Confirm internet access from a wired workstation, secure Wi-Fi access, guest network separation, DNS resolution, cloud applications, printing, VoIP calling, VPN access, and any point-of-sale or line-of-business applications that depend on network connectivity.

For a FortiGate, also inspect security policies, routing, SD-WAN health checks, web filtering behavior, intrusion prevention status, and logs. Review whether interfaces negotiated correctly and whether high availability members, if present, have synchronized as expected. A quick visual check of the dashboard is useful, but targeted testing produces better evidence that the network is ready for users.

How Often Should Business Firmware Be Reviewed?

A quarterly review is a practical baseline for most businesses. During that review, identify available security fixes, changes in support status, known issues affecting your environment, and any upcoming business project that could require a version change. This is a review cycle, not necessarily an update cycle.

Many stable environments schedule routine firmware maintenance once or twice per year, with separate emergency procedures for serious security advisories. Higher-risk organizations, businesses with compliance requirements, or companies that rely heavily on remote access may need more frequent evaluation. Conversely, a change freeze during a critical season may be reasonable, provided severe vulnerabilities are still addressed through approved emergency changes.

The larger concern is unmanaged drift. If no one owns firmware planning, configurations age, warranties expire, subscriptions lapse, and the eventual maintenance window becomes longer and less predictable. Managed support turns firmware from a reaction to an operational discipline.

A Practical Decision Before Every Update

Before approving the change, ask four questions: Does this release address a security or reliability issue that affects us? Is the upgrade path supported for our exact hardware and current version? Can we test the services our staff and customers depend on? Do we have a verified backup and rollback option?

If those answers are clear, firmware maintenance is a controlled investment in availability and risk reduction. If they are not, pause and build the plan first. The safest update is not simply the newest one - it is the one that is justified, compatible, tested, and performed with accountability for what happens next.