Skip to main content
WeekEnd-Engineer
Explorer
January 27, 2026
Solved

Critical issue | FortiGate ON-Prem lost Serial Number after upgrade from 7.4.8 to 7.4.10

  • January 27, 2026
  • 3 replies
  • 1718 views

 

Environment

  • Platform: FortiGate (hardware appliance)

  • HA mode: Active / Passive

  • FortiOS current version: 7.4.8

  • Target version: 7.4.10

  • HA priorities:

    • Unit A (Master): priority 200

    • Unit B (Slave): priority 100

Expected upgrade behavior (normal case)

Based on Fortinet documentation and past experience, the expected HA upgrade sequence is:

  1. Firmware upgrade starts on the slave unit (B).

  2. Slave reboots and temporarily disconnects from HA.

  3. Cluster fails over to the upgraded slave.

  4. Firmware upgrade is then applied to the former master (A) in background.

  5. Final failback occurs according to HA priority (unit A becomes master again).

Observed behavior / Issue description

During the upgrade from 7.4.8 to 7.4.10 (firmware uploaded via GUI using .out file downloaded from fortinet official source):

  • The upgrade process took more than 20 minutes, significantly longer than usual.

  • HA became disconnected, and unit B (slave) was no longer visible from the cluster GUI.

  • Accessing unit B directly via Console & Management port (HTTPS)

I observed the following:

  • FortiOS 7.4.10 was installed successfully.

  • The license was present and recognized.

  • However, the serial number had changed to: FGT1XX0000000001

This serial number appears to be a generic / placeholder serial, which is highly concerning in a production environment.

Immediate mitigation actions taken

To protect the production environment, I took the following steps:

1. HA isolation

  • Physically disconnected the HA interface cable on unit B.

  • Objective: prevent any risk of synchronization or propagation of the issue to the master unit (A).

2. Manual downgrade on unit B

  • Performed a manual downgrade on unit B to FortiOS 7.4.8 using the .out file.

  • After reboot:

    • Original serial number was restored

    • Configuration was intact

    • System behavior returned to normal

3. HA reconnection

  • Reconnected the HA interface cable.

  • Cluster returned to a stable Active/Passive state.


Questions for the Fortinet community

1. Incident handling

  • Was isolating the HA link and downgrading the slave the correct remediation approach in this situation?

  • Are there safer or recommended containment procedures when a unit shows a default serial number after an upgrade?

2. Root cause analysis

  • What could cause a FortiGate to:

    • Boot with a generic serial number

    • While still recognizing its license?

3. Troubleshooting methodology

What would be the recommended diagnostic steps to investigate this type of incident?

Examples:

  • Specific diagnose sys ha or diagnose hardware commands

  • Logs to collect before retrying the upgrade

  • Whether execute factoryreset or execute restore image is recommended in such cases

  • Whether Fortinet advises offline upgrade (console + TFTP) instead of GUI for HA clusters, and is it recommanded to start upgrade from Slave one.

4. Prevention / best practices

  • Are there known issues upgrading HA clusters from 7.4.8 to 7.4.10? (nothing about SN changing mentionned in release Note)

  • Any Fortinet advisories related to serial number anomalies during upgrade?

  • Recommended pre-upgrade checks specific to HA environments?

 

Maybe someone struggled with same issue?

I will apprecaite any advise how to deal with it.

Many thanks

Best answer by WeekEnd-Engineer

Following further investigation and Fortinet’s latest publication, here is the root cause and resolution regarding the issue:

Issue Summary
After upgrading from FortiOS 7.4.8 to 7.4.10-7.4.11 and other versions, several FortiGate D-Series models lost their original serial number, which was replaced by:FGT0000000000001

 

Root Cause
The issue impacts FortiGate D-Series appliances running older BIOS versions (notably BIOS 04.x).
During the upgrade to FortiOS versions 7.4.10, 7.4.11, 7.6.5, or 7.6.6, the outdated BIOS causes incorrect hardware identification handling, leading to serial number corruption.

This is officially tracked under Known Issue ID 1252663.

 

Fortinet Action Taken
Fortinet has:

  • Withdrawn the affected builds.

  • Released corrected images under a special branch.

  • Published build 6800 for impacted D-Series models (800D, 900D, 1000D, 3000D, 3100D, 3200D, 3700D).

  • Confirmed that the special branch must show Branch point: 2878 (verify using get system status).

If the serial number has already changed, Isolate affected FortiGate D-series devices and perform a downgrade.

The discussion can be considered resolved as Fortinet has officially addressed the defect and replaced the affected firmware builds.

Thank you to everyone who contributed to the investigation.

 

Many thanks to everyone for your interest.

3 replies

HarryTran
Staff
Staff
January 27, 2026

Hi @WeekEnd-Engineer,

Thanks for your detail feedback!

Could you let me know the model of your FortiGates, I will try to duplicate the issue in my lab?

Regards,

Harry

WeekEnd-Engineer
Explorer
January 28, 2026

Hello @HarryTran,

the model is FG 1000D, thank you for your interest.

Best regards.

HarryTran
Staff
Staff
January 28, 2026

Thanks for your info, @WeekEnd-Engineer 

HarryTran
Staff
Staff
February 2, 2026

Hi @WeekEnd-Engineer 

I’ve attempted the HA upgrade multiple times but haven’t been able to reproduce the issue. I also tested an upgrade path from 7.4.8 to 7.4.11, and the issue did not occur there either. I’ll continue monitoring for any similar symptoms and will keep you updated if I notice anything.

Regards,

Harry

WeekEnd-Engineer
Explorer
February 15, 2026

 

Hi Harry,

Thanks for testing.

In the failing cases (mine and @IainACNET ), the units are running: BIOS version: 04000009

Units with BIOS 05000004 do not seem to be affected.

Could you confirm which BIOS version your 1000D is using? This may be BIOS-related rather than FortiOS-specific.

Also, both 7.4.11 and 7.6.6 release notes reference Bug ID 1252663 (serial number change after upgrade), which matches the behavior we’re seeing.

At this point, it looks strongly correlated with BIOS v4 hardware.

I’ll share any updates if TAC provides clarification.

IainACNET
New Member
February 12, 2026

Exact thing happened to me, 7.4.9 to 7.4.11 1000D standalone.

 

1 x 1000D upgraded no issue
1 x 1000D different site upgrade, reboots, serial number reset to FGT0000000000001 no licence loaded, limited to 3 vdoms, doesn't load any Firewall policy, can't add more than 3 looks like it goes into trial mode. I have 2 recently removed 1000D in the office, I'll upgrade these tomorrow and see if I can replicate the issue on these models

 

Have a ticket opened with Support about it, various other models upgraded no issue.

One thing we have noticed different bios version

 

BIOS version: 04000009 failed upgrade

BIOS version: 05000004 successful upgrade

 

 

IainACNET
New Member
February 13, 2026

So I've managed to replicate this again on a 3rd 1000D running the version 4 bios, same issues no policies, serial number reset to FGT0000000000001 , if the bios is the version 5 no issues

WeekEnd-Engineer
Explorer
February 15, 2026

 

Thanks for your feedback — this is very interesting and aligns with what I experienced.

In my case, the affected unit is also running:BIOS version: 04000009

So this seems consistent with what you are observing:
BIOS v4 → issue
BIOS v5 → no issue

Additionally, something important on my side:

Fortinet has removed the direct upgrade path from 7.4.8 to 7.4.9.
The official upgrade path now only proposes:

  • 7.4.11

  • 7.6.6

Both release notes (7.4.11 and 7.6.6) mention Bug ID 1252663, which explicitly refers to an issue where the serial number may change/reset after upgrade.

This strongly suggests that the problem is already known internally.

However, despite having an open support ticket, no clear technical explanation has been provided so far regarding:

  • The root cause

  • Why it seems BIOS-dependent

  • Or whether a BIOS upgrade is required prior to FortiOS upgrade

Given your replication results, this now looks very likely tied to BIOS v4 hardware batches of 1000D.

Questions that remain open:

  • Is Fortinet planning a BIOS upgrade package?

  • Is upgrading via console/TFTP safer than GUI in this case?

If you get feedback from TAC on your ticket, please share — this looks like a model-specific regression rather than a generic FortiOS issue.