ANTMINER Security Firmwares Q&A

Security firmware is Bitmain’s cryptographically locked-down firmware line. It signs every update with an RSA key the miner checks before it will flash, disables the SSH shell, and refuses to be downgraded. It closes the doors that farm-wide worms used to walk through — but it is a one-way door for you too. Once it’s on, you lose SSH, you lose the option to run custom tuning firmware, and you can’t roll back. This guide answers the common questions and tells you what the marketing FAQ doesn’t: what you trade away, and how to decide.

What the security firmware actually is

“Security firmware” is not a separate feature bundle — it’s stock Antminer firmware with a hardened trust chain bolted on. Three things change under the hood:

• Signed updates. Every firmware image is signed with RSA-2048 and verified with SHA-256 before it installs. The miner checks the image’s embedded public key against its own on-board key, verifies a signature on each file, and then verifies a compound hash over the whole package. Fail any layer and the flash aborts.
• SSH disabled. The on-board SSH daemon has been locked shut since the 2019 security push. You cannot open a root shell over the network, full stop.
• Anti-downgrade. After security firmware is installed, the miner rejects older or unsigned images. That’s the origin of the Cannot Find Signature!!! error people hit when they try to go back.

Why Bitmain shipped it

This wasn’t theoretical. Through 2018–2019 a wave of worms jumped between Antminers over the local network, exploiting default credentials and the open shell. They rewrote pool and wallet configs to quietly steal hashrate, and at least one strain tried to brick infected units outright. In a hashcenter with hundreds of machines on one flat network, a single compromised miner could poison the whole floor. Signing the firmware and killing the remote shell removed the two things those worms depended on: the ability to push a tampered image, and the ability to log in remotely.

How to tell if you’re running security firmware

1. The download page says so. The manufacturer’s support portal flags security builds in the description next to each model’s firmware.
2. The filename. Signed security builds carry a sig marker in the filename — that’s the signature payload the miner verifies.
3. SSH is refused. If a connection to port 22 is closed or the shell is gone, you’re on a locked build. This is the fastest field test.
4. Downgrades bounce. If an older image throws Cannot Find Signature!!!, the machine is already on security firmware.

The lockdown is a one-way door

This is the part the vendor FAQ glosses over. Security firmware is a permanent commitment, not a toggle:

• No rollback. You can move forward to newer signed builds, but you cannot go back to a pre-security version. The anti-downgrade check blocks it by design.
• No third-party / custom firmware. Because the bootloader only accepts images signed by the manufacturer’s key, community and custom tuning firmware — the kind used for autotuning, undervolting, or squeezing efficiency out of an aging board — will not install.
• No SSH diagnostics. You lose direct shell access for reading logs, checking chain voltages per domain, or scripting repairs. You’re limited to the web UI and the CGMiner API on port 4028.

None of this is a shock or fire hazard — the risk here is purely operational lock-in. Decide before you flash, not after.

“System Upgrade Failed — Cannot Find Signature!!!”

This means the image you’re trying to install is not a signed security build, and the miner — already running security firmware — refuses it. It is working exactly as intended. To resolve it:

• Download the correct signed firmware for your exact model from the manufacturer’s official support portal. Match the model precisely (an S17 image will not install on an S17 Pro).
• Do not try to force an older or third-party image — the signature check will keep rejecting it. There is no web-UI path back off security firmware.
• If the unit is stuck or half-flashed, treat it as a recovery job (below), not an upgrade retry.

Which models have it

The first security wave covered the Zynq-based generation — S9, S9i, S9j (BM1387), S15/T15, and the S17/T17/S17 Pro family (BM1397) — plus Scrypt and older units like the L3+ (BM1485), DR5, and Z11. Coverage keeps expanding, so don’t trust a static list: check the current security-build status for your model on the official portal before you flash: service.bitmain.com.cn/support/download.

Recovering a bricked or locked unit

If a flash fails part-way or the control board won’t boot, the recovery path is the manufacturer’s SD-card recovery image, not the web UI:

1. Write the official recovery image for your model to a microSD card, seat it in the control board’s slot, and power-cycle to boot from card.
2. Let it re-flash the on-board firmware, then remove the card and reboot to internal storage.
3. Remember the anti-downgrade rule still applies — recovery restores a signed build; it does not unlock the machine or bring SSH back.

If the control board is genuinely dead (no boot, no DHCP lease, no web UI after a clean SD recovery), the fault is usually hardware, not firmware — a failed eMMC/NAND, blown regulator, or a bad board. That’s a repair-bench problem, not a re-flash.

The sovereign angle

Security firmware trades control for convenience: the manufacturer hardens the box, and in exchange you run it their way. That’s a fair deal for a set-and-forget hashcenter. But if you self-repair and tune your own hardware, the lockout costs you the tools you rely on. The sovereign alternative is to keep an open firmware and do the hardening yourself: put miners on an isolated management VLAN with no inbound internet, never port-forward a miner, kill every default password, and keep the web/API ports off the open internet. Done properly, that closes the same attack surface the worms used — without surrendering your shell or your ability to flash what you choose. For miners who want that control by default, an open, auditable firmware such as DCENT_OS keeps the doors you’d otherwise weld shut.

Related: Pull the correct signed image and recovery files from our manuals and firmware library, brush up on the terms in the firmware glossary entry, and if a unit stays dark after a clean SD recovery, start a repair and let the bench take it from there.