F5 BIG-IP Hardening Guide: TMUI, iControl REST, Self IPs

F5 BIG-IP devices front critical applications, yet the most damaging BIG-IP vulnerabilities have been in the management plane: the Configuration utility (TMUI) and iControl REST, reached through the management port or through self IP addresses that were never locked down. CVE-2020-5902, CVE-2021-22986, CVE-2022-1388 and CVE-2023-46747 all gave unauthenticated attackers system command execution and all sit in the CISA Known Exploited Vulnerabilities catalogue. In October 2025 F5 disclosed that a nation-state actor had stolen BIG-IP source code and information about undisclosed vulnerabilities, and CISA's Emergency Directive 26-01 told US federal agencies to inventory devices, check management interface exposure and patch within a week. This guide covers BIG-IP administrator and API identity, the management plane settings that shrink exposure, logging, and the mistakes behind most compromises. It is for application delivery engineers, network architects and SOC analysts. For the generic view, see the Load Balancer Security Guide.

Key takeaways

Self IPs are a management path. KEV entries for CVE-2023-46747 and CVE-2023-46748 describe exploitation through the management port and/or self IP addresses; set Port Lockdown to Allow None on every self IP that does not need management or control traffic.
The httpd allow list defaults to All. Restrict sys httpd allow (and the SSH equivalent) to management subnets so TMUI and iControl REST answer only to administrators.
Use the narrowest role. BIG-IP has more than fifteen built-in roles, from Administrator to Operator, Auditor and Guest, scoped by partition; most people and automation need far less than Administrator.
iControl REST tokens are short by default; keep them so. Tokens expire after 1200 seconds and can be extended to 36,000; automation should use token authentication against a dedicated account rather than basic authentication with an admin password.
Assume attackers know the code. After the 2025 source code theft, patch cadence and management exposure decide risk; treat new BIG-IP advisories as urgent and keep the management plane unreachable.

How identity and access work in F5 BIG-IP

BIG-IP runs TMOS on hardware, VELOS and rSeries chassis (with F5OS underneath), and as BIG-IP Virtual Edition. Management reaches the system in several ways.

Interface	Reached through	Identity used	Exposure control
Configuration utility (TMUI)	HTTPS on the management port, or on a self IP whose Port Lockdown allows it	Local or remote user with a role	`sys httpd allow`, Port Lockdown, management network ACLs
iControl REST	Same HTTPS service under `/mgmt/`	Basic authentication (local accounts) or token from `/mgmt/shared/authn/login`	Same as TMUI
SSH (tmsh or advanced shell)	Management port, or self IP if allowed	Local or remote user with terminal access; root	`sys sshd allow`, Port Lockdown, terminal access per user
F5OS platform layer (VELOS, rSeries)	Separate management interfaces	Separate F5OS accounts	Treat as its own management plane
BIG-IQ Centralized Management	BIG-IQ console and API	BIG-IQ users; BIG-IQ holds credentials for managed devices	Same protection as BIG-IP; CVE-2021-22986 affected both

Data plane users (application users, and remote users of BIG-IP Access Policy Manager) authenticate through access policies on virtual servers. APM flaws are a separate KEV stream (CVE-2025-53521 and an OAuth-related APM overflow added in 2026), so the APM virtual server needs the same patch urgency as the management plane.

Machine identities on BIG-IP include iControl REST tokens and the accounts behind them, remote authentication bind accounts and shared secrets, SNMP credentials, certificates and private keys for every client SSL and server SSL profile, device trust certificates between HA peers, and the credentials BIG-IQ or automation tools (Ansible, Terraform, AS3 pipelines) hold. UCS archives contain the configuration and keys, so backups are as sensitive as the device.

Admin roles and privileged access

BIG-IP roles to use

Role	What it can do	Typical holder
Administrator	Full control of all objects, all partitions	Very few people; break-glass
Resource Administrator	Nearly all objects except other user accounts	Senior ADC engineers
Manager	Virtual servers, pools, nodes, profiles, monitors, iRules in assigned partitions; TMSH only	Application delivery team per partition
Certificate Manager	Certificates, keys and FIPS operations	PKI team or certificate automation
Application Editor, Operator	Pools and members; enable or disable nodes and members	Release automation, operations staff
Auditor, Log Manager, Guest	Read-only access (Log Manager can also edit logging settings)	Auditors, SOC, monitoring integrations
No Access	Blocks all access	Default for remote users not mapped to a role

F5's documentation notes that when terminal access is granted to most roles, the user reaches TMSH but not the advanced shell. Grant terminal access only where needed, and keep advanced shell (bash) access to the smallest group possible, because bash bypasses role controls.

Remote authentication: configure RADIUS, TACACS+ or LDAP and AD remote authentication with MFA at the provider, and use remote role mapping so directory groups map to BIG-IP roles and partitions. Set the default role for unmapped remote users to No Access.
Local accounts: keep the local admin account and root as vaulted break-glass credentials with long unique passwords; disable root SSH login where your operations allow it, and on platforms licensed for Appliance mode consider enabling it to remove advanced shell and root access entirely. See the Break-Glass Account Guide.
Partitions: use administrative partitions so application teams manage only their own objects.
Session controls: the GUI idle timeout (auth-pam-idle-timeout) defaults to 1200 seconds; auth-pam-validate-ip (on by default) ties a GUI session to its source IP, so leave it on. auth-pam-dashboard-timeout is off by default, meaning an open dashboard never times out; turn it on.
Jump hosts: reach the management network only from recorded administrative jump hosts. See the Privileged Session Management Guide.

Integrations, API tokens and service accounts

Token authentication: POST credentials to /mgmt/shared/authn/login with a loginProviderName (tmos for local, or the remote provider), then send the token in the X-F5-Auth-Token header. Tokens last 1200 seconds by default and can be extended by PATCH up to 36,000 seconds. Basic authentication works only for local accounts, so remote-authenticated automation must use tokens. Delete tokens when a job finishes rather than letting them run to expiry.
Dedicated automation accounts: each pipeline (AS3, Declarative Onboarding, Ansible, Terraform) gets its own account with the narrowest role and partition. Declarative Onboarding has no credentials of its own and needs administrator credentials for the BIG-IP, so run it from a controlled pipeline and rotate those credentials after use. Store all of them in a secrets manager. See the API Key Management Guide.
BIG-IQ: holds credentials for every managed BIG-IP. Treat it as a tier-0 system: same patching urgency, management isolation and MFA as the devices.
Remote authentication secrets: RADIUS and TACACS+ shared secrets and LDAP bind accounts need owners and rotation; use LDAPS. See the RADIUS Security Guide.
Certificates and keys: inventory every SSL profile key, use the Certificate Manager role or automation for renewal, and consider hardware or FIPS key protection for high value keys. After a confirmed compromise, re-issue them all.
Backups: UCS archives and qkview files contain configuration and, for UCS, keys. Encrypt UCS archives with a passphrase, restrict storage access and remove old copies.

Logging and detection

Send BIG-IP logs to a remote syslog collector or SIEM. The audit log records configuration changes made through TMUI, TMSH and iControl REST with the user; authentication events record logins and failures; the REST framework logs show API calls.

Signal	What it can mean	Response
TMUI or iControl REST requests from addresses outside the management range	httpd allow list or Port Lockdown gap; exploitation attempt	Fix exposure immediately; hunt for prior access
New local users, role changes, or remote role mapping changes	Attacker persistence (the CVE-2022-1388 and CVE-2023-46747 class allowed system command execution)	Verify against change records; treat unexplained as compromise
Changes to `sys httpd allow`, `sys sshd allow` or Port Lockdown	Management exposure widened	Alert and review
Root or advanced shell logins	Break-glass use or attacker activity	Every event should match an approved ticket
Unexpected files, cron entries or modified iRules	Web shell or traffic manipulation after exploitation	Isolate, collect a qkview and disk image, rebuild
Log forwarding stops	Tampering or failure	Silence alert per device

For the 2025 incident, F5 described a highly sophisticated nation-state actor with long-term access, and press coverage citing Bloomberg linked the intrusion to BRICKSTORM malware; see the BRICKSTORM Backdoor Guide for that family. For network device log use in general, see the Network Device Syslog and Configuration Change Detection Guide.

Metrics

Self IP lockdown: percentage of self IPs set to Allow None or an explicit Allow Custom list (target: none left on Allow All).
Management reachability: BIG-IP and BIG-IQ management services reachable from the internet or user networks (target: zero).
Patch latency: days from an F5 Critical or High advisory to fixed code on every device, measured against the one-week window ED 26-01 set.
Privileged accounts: number of Administrator role holders and accounts with advanced shell access.
Automation hygiene: automation accounts using tokens and dedicated roles versus admin basic authentication.

Hardening baseline

Inventory (week 1): every BIG-IP, VE, F5OS chassis and BIG-IQ, with version, modules (LTM, APM, ASM), support status and which interfaces and self IPs exist. Disconnect or replace end-of-life devices, as ED 26-01 required for federal agencies.
Close management exposure (week 1): set Port Lockdown to Allow None on external and user-facing self IPs, Allow Custom with only required ports (for example BGP or HA) elsewhere; restrict sys httpd allow and sys sshd allow to management subnets; confirm by external and internal scans that TMUI, iControl REST and SSH do not answer. Change one HA pair first and confirm config sync and failover still work, because device trust and sync use self IPs; roll back by restoring the Port Lockdown setting or a UCS taken beforehand.
Patch (week 1 to 2): move to fixed releases for all KEV-listed BIG-IP and BIG-IQ vulnerabilities, upgrading the standby device of a pair first. Take a UCS before each upgrade.
Rebuild administration (weeks 2 to 6): remote authentication with MFA and role mapping, default No Access for unmapped users, partitions, minimal terminal and advanced shell access, vaulted admin and root.
Machine credentials (weeks 4 to 8): dedicated automation accounts using tokens, secrets in a vault, rotated remote authentication secrets, SNMPv3, encrypted UCS archives.
TLS on the management service: replace the self-signed management certificate, remove 3DES from ssl-ciphersuite and older protocols from ssl-protocol (the default only removes SSLv2 and SSLv3), and turn on the dashboard idle timeout.
Logging (weeks 2 to 8): remote syslog for audit, authentication and REST logs, alerts on the signals above, and a monthly configuration comparison against a baseline.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1	ATT&CK technique addressed
Self IP lockdown and httpd allow list	SC-7, CM-7	PR.PS-01	4.1, 4.8, 12.3	T1190 Exploit Public-Facing Application
Patching BIG-IP, BIG-IQ and APM	SI-2	ID.RA-01, PR.PS-02	7.7	T1190 Exploit Public-Facing Application
Roles, partitions, remote auth with MFA	AC-6, IA-2, AC-2	PR.AA-01, PR.AA-05	5.4, 6.5, 6.8	T1078 Valid Accounts, T1098 Account Manipulation
Token and automation credential hygiene	IA-5	PR.AA-01	3.11	T1552 Unsecured Credentials
Web shell and change detection	SI-4, CM-3, AU-6	DE.CM-09	8.2, 8.11	T1505.003 Web Shell
Log forwarding and silence alerts	AU-9	PR.PS-04	8.9	T1685 Disable or Modify Tools

ISO/IEC 27001:2022 Annex A equivalents are A.8.2, A.8.5, A.8.8, A.8.9, A.8.15, A.8.20 and A.8.24.

Common misconfigurations

Self IPs left on Allow Default or Allow All: the management service then answers on application-facing addresses, which is how management plane flaws such as CVE-2023-46747 reach devices whose management port is isolated.
Isolated management port, open httpd allow list: the allow list defaults to All, so the only protection is the network path. Set it explicitly as a second layer.
Automation using the admin account with basic authentication: one leaked script exposes full control, and the audit log cannot distinguish pipelines from people. CVE-2022-1388 showed how much an iControl REST authentication bypass is worth to an attacker.
Everyone given Administrator and bash: role controls are only as strong as the advanced shell population.
Forgetting BIG-IQ and F5OS: BIG-IQ shared CVE-2021-22986 with BIG-IP and stores device credentials; F5OS chassis management is a separate plane with separate accounts.
Patching without hunting: fixing the flaw does not remove accounts, iRules or files an attacker added. Compare configuration with a pre-incident UCS and rotate every secret if there is any doubt. The same lesson came out of the Ivanti Connect Secure exploitation of 2024 on another vendor's appliance.

Practitioner checklist

Inventory every BIG-IP, VE, F5OS chassis and BIG-IQ with version, modules and support status; retire end-of-life devices.
Set Port Lockdown to Allow None on all self IPs that do not need management or control traffic.
Restrict sys httpd allow and sys sshd allow to management subnets and verify by scanning.
Run fixed releases for every KEV-listed BIG-IP, BIG-IQ and APM vulnerability.
Use remote authentication with MFA and role mapping; default unmapped users to No Access; use partitions.
Keep Administrator and advanced shell access to a handful of named people; vault admin and root.
Give each automation pipeline its own least-privilege account using iControl REST tokens, with secrets in a vault.
Remove 3DES and old TLS versions from the management service, replace its certificate and enable the dashboard idle timeout.
Forward audit, authentication and REST logs to the SIEM and alert on user, role and exposure changes.
Encrypt UCS archives and keep a pre-change UCS for comparison and rollback.

F5 BIG-IP Hardening Guide: Locking Down TMUI, iControl REST and Self IPs