An RSA SecurID deployment is only as strong as the administrators, token seed records and agent secrets behind it, because anyone who controls those can issue, reassign or bypass the second factor for every protected VPN, server and application. SecurID is often the MFA layer in front of remote access and privileged systems, so review its Super Admin accounts, appliance passwords and agent configuration regularly rather than leaving them as installed. This guide covers hardening RSA Authentication Manager (the on-premises or cloud-hosted virtual appliance) and the RSA ID Plus cloud service administered through the Cloud Administration Console, using RSA's own documentation: administrative accounts and roles, token record import, node secrets for authentication agents, lockout policy, step-up authentication for cloud admins, and logging. It is written for identity engineers and administrators who own a SecurID deployment. For OTP fundamentals, see the Authenticator Apps and OTP Guide.
This is an independent guide from NHI Mgmt Group, based on RSA's public documentation as of November 2026. It is not sponsored or reviewed by RSA. Product features change, so confirm settings against RSA's current documentation.
Key takeaways
- Three account types control the appliance. The Security Console Super Admin, the Operations Console administrator and the
rsaadminoperating system account each need separate owners, separate credentials and audit. - Token record files are seed material. RSA documents that software token records hold the seed, so the XML file and its file password must be handled like private keys from delivery to deletion.
- Node secrets are shared encryption keys. The node secret encrypts traffic between an agent and Authentication Manager; manual delivery with a separately transmitted password is RSA's stronger option.
- Admin accounts should not be directory accounts. RSA advises against linking Authentication Manager administrative roles to external LDAP or Active Directory accounts, and recommends security domains to limit scope.
- Cloud admins need step-up authentication. The Cloud Administration Console signs in with a password unless Additional Authentication is enabled, which adds a tokencode or push approval.
How identity and access work in RSA SecurID
RSA Authentication Manager (AM) holds users (from its internal database or linked LDAP and Active Directory identity sources), the token records assigned to them and the authentication agents that are allowed to send requests. A protected resource, such as a VPN gateway, Windows or UNIX host or web server, runs an RSA authentication agent or speaks RADIUS to AM. The user enters a passcode, the agent forwards it, and AM validates it against the token's seed. The cloud service extends this with additional methods managed in the Cloud Administration Console, such as Approve push notifications, and assurance levels that group methods by strength.
AM is administered through two consoles. The Security Console manages users, tokens, agents, policies and administrative roles. The Operations Console manages the appliance itself: backups, replication, network and logging configuration, and recovery tasks. Under both sits the appliance operating system.
| Account | Purpose (per RSA) | Hardening note |
|---|---|---|
| Super Admin (Security Console) | Full control in all security domains; creates other Super Admins, builds the domain hierarchy, links identity sources | RSA recommends saving the Super Admin role in the top-level domain so lower-level admins cannot change its password; a small number of named holders |
| Operations Console administrator | Appliance tasks and command line utilities, including recovering the Super Admin account; stored outside the AM internal database | Can recover Super Admin, so it is equally privileged; a lost password cannot be recovered, but a Super Admin can create a new account |
rsaadmin (appliance OS) | Advanced maintenance and troubleshooting; its password gives sudo and shell access | RSA says to restrict and audit access tightly; SSH must be enabled in the Operations Console before it can be used, so leave SSH off unless needed; RSA provides no recovery utility for this password |
root (appliance OS) | Present by default, not needed for normal tasks | RSA documents that you cannot log on to the appliance with it |
The ATT&CK techniques relevant to SecurID infrastructure are T1078 Valid Accounts (a compromised administrator), T1098 Account Manipulation (assigning a token or emergency code to an attacker-controlled account), T1556 Modify Authentication Process (changing agent or policy configuration to bypass MFA) and T1111 Multi-Factor Authentication Interception (capturing passcodes in transit).
Admin roles and privileged access
AM delegates administration through roles and security domains. A role's scope is the set of security domains and identity sources it applies to; a role saved in a domain governs that domain and those below it, never above. Permissions are granted as All, Add, Edit, Delete or View, and can be set per custom identity attribute as None, Read-Only or Modify. Administrators can only assign privileges they hold themselves.
- Least privilege by domain: RSA recommends granting only the permissions each task needs and keeping scope as narrow as the work allows. Split the hierarchy so help desk staff for one business unit cannot touch another's users or tokens.
- Separate accounts, no shared credentials: each administrator gets an individual account; RSA advises not sharing credentials and not linking administrative roles to external LDAP or Active Directory accounts. A domain compromise then does not automatically become a SecurID administrator compromise. See the Privileged Access Management Guide.
- New duties, new role: RSA recommends creating a separate role for added duties rather than expanding a shared role, which would change access for everyone holding it.
- Help desk risk: help desk roles can unlock users and, in the cloud console, generate emergency tokencodes and device registration codes. These are exactly the actions a social engineer asks for, so pair them with the caller verification in the MFA Fatigue and Bypass Guide.
Cloud Administration Console
| Cloud role | Powers (per RSA) | Hardening note |
|---|---|---|
| Super Admin | Unrestricted privileges in the Cloud Administration Console, including adding and editing administrators, identity routers and service settings | RSA recommends more than one Super Admin so one can reset another's password if locked out; keep the number small |
| Help Desk Admin | View users, delete registered authenticators, generate device registration codes and emergency tokencodes, unlock SMS, voice and Authenticate tokencodes, enable or disable non-administrative users | Deleting an authenticator and issuing a registration code is a takeover path; log and review every use |
Administrators sign in to the Cloud Administration Console with a console password by default. Additional Authentication, enabled by a Super Admin under My Account, Company Settings, Sessions and Authentication, applies an access policy so admins must also present a tokencode or Approve push; the console then acts as a SAML service provider to the cloud identity service. RSA states that FIDO is not supported for protecting the console, and each admin needs a synchronised identity source user with the same email address and an enrolled authenticator. If no Super Admin can complete step-up, RSA Customer Support can disable the requirement temporarily and emails all Super Admins when it does. That support path is itself a recovery channel worth knowing about. See the SaaS Admin Account Protection guide.
Integrations, API tokens and service accounts
The machine credentials in a SecurID deployment are token seed records, agent node secrets, RADIUS client secrets and the credentials AM uses to bind to LDAP and Active Directory identity sources.
| Secret | What RSA documents | Protection |
|---|---|---|
| Token record file | Supplied by RSA as XML; for software tokens each record holds the seed and metadata such as serial number, expiry, tokencode length and interval; may be password protected; imported via Authentication, SecurID Tokens, Import Tokens Job into a chosen security domain | Store encrypted until import, keep the file password in a separate channel, import into the right domain (the default is the top-level domain), then delete working copies under your key-handling procedure |
| Node secret | Shared secret used as a symmetric key between agent and AM; generated automatically after the first successful authentication, or created manually (Access, Authentication Agents, Manage Existing, Manage Node Secret) with an encryption password of up to 16 characters | RSA describes manual delivery as stronger: deliver the file on external media through trusted personnel, give the password verbally, and if emailed send the password separately |
| User and token export file | AM encrypts the export file used to move users and tokens between deployments; exported users still exist in the source until deleted | Delete migrated users from the source so they cannot keep authenticating there |
| Identity source bind account | Links AM to LDAP or Active Directory | Read-only service account, vaulted password, monitored for interactive logon. See the How to find service accounts with Domain Admin rights guide |
- Agent registration: register each agent explicitly; the Security Console lists agents as Restricted or Unrestricted, and restricted agents only pass requests from members of user groups that have been granted access, so use them for sensitive systems.
- Clearing a node secret: when an agent host is rebuilt or suspected compromised, clear the node secret on AM and on the agent together; clearing only one side breaks authentication.
- TCP agents: RSA notes that TCP-based agents negotiate a key dynamically to encrypt the channel and that a node secret file is optional for them, whereas UDP agents rely on the node secret. Prefer current TCP agents where the protected platform supports them.
- RADIUS: many network devices use RADIUS rather than an agent; protect RADIUS shared secrets with the guidance in the RADIUS Security Guide.
Logging and detection
AM logs to its internal database and can also forward all messages to a remote syslog server. For AM 8.8 and later, RSA documents forwarding over TCP with TLS (the rsyslog gtls driver, TLS 1.3, x509 name authentication), configured in /etc/rsyslog.d/remote.conf with the server certificate in /opt/rsa/am/certs/remoteSyslogServer. RSA notes that syslog settings are not included in backups, so remote logging must be reconfigured after restoring a primary or replica. The Log Data Masking setting controls how many digits (0 to 12, default 12) of a token serial number appear in logs sent to external destinations, and applies to all instances.
| Event to watch | Why | Response |
|---|---|---|
| Administrator added, role or scope changed | Privilege escalation inside AM or the cloud console | Confirm against a change ticket |
| Token assigned, replaced or reassigned, emergency or on-demand tokencode issued | Classic help desk social engineering outcome | Call back the user on a known number |
| Agent added or node secret cleared | New system trusted to send authentication requests | Verify the host owner |
| Token import job | New seeds entering the deployment | Match to a purchase or provisioning record |
| Repeated failures then lockout | Guessing or spraying | Check source agent and user |
SSH enabled, rsaadmin login | OS-level access to the appliance | Expected only during maintenance windows |
Metrics:
- Number of Super Admin and Operations Console administrator accounts, and how many are linked to directory accounts (target: none linked).
- Emergency and on-demand tokencodes issued per month, with the share verified by callback.
- Days with SSH enabled on any appliance.
- Remote syslog delivery gaps, and whether it was reconfigured after the last restore.
- Unassigned token records older than a set age, and token record files still stored outside AM.
Hardening baseline
- Inventory: list Super Admins, Operations Console administrators, roles and scopes, agents (restricted and unrestricted), RADIUS clients, identity sources and stored token record files.
- Fix administrator identity: give each admin a separate account not linked to LDAP or Active Directory, save the Super Admin role at the top-level domain, and move delegated admins into lower domains with narrow roles.
- Lock down the appliance: restrict who knows the
rsaadminpassword, keep SSH disabled except in maintenance windows, and store recovery credentials in a vault, as RSA advises. - Review lockout policy: the default policy locks an account after five consecutive failures within one day and requires an administrator to unlock it. Lockout policies are assigned per security domain and do not inherit to new subdomains, which use the default, so check every domain.
- Protect seeds and agents: handle token record files and node secrets as described above; move sensitive agents to restricted mode and manual node secret delivery.
- Protect cloud admins: enable Additional Authentication for the Cloud Administration Console after confirming at least one Super Admin can complete the step-up method.
- Log and mask: configure TLS remote syslog to the SIEM, set Log Data Masking to the fewest serial number digits your operations need, and alert on the events above.
Testing and rollback: trial lockout and access policy changes on a test security domain before applying them to production domains; keep a Super Admin who is not subject to the change and verify a second Super Admin exists before enabling cloud step-up. Small versus large: a small deployment may have one primary and one replica with two admins, where separation of the three appliance accounts matters most; a large deployment benefits most from a deliberate security domain hierarchy and per-domain lockout policies.
Common misconfigurations
- Super Admin mapped to an Active Directory account: a domain compromise becomes control of the MFA system that was meant to contain it.
- One person knows every appliance password: RSA provides no recovery for
rsaadmin, and the Operations Console administrator can recover Super Admin, so concentration creates both a single point of failure and a single point of compromise. - Token record files left on file shares: software token records contain seeds; an old XML file and its password in the same folder is a cloneable authenticator for every token in it.
- Agents left unrestricted: any user with a token can authenticate to the protected resource unless the agent is restricted to specific users or groups.
- Remote syslog lost after a restore: because syslog settings are not backed up, a recovered appliance can silently stop forwarding logs.
- Cloud console protected by password only: without Additional Authentication, a phished console password grants Super Admin or Help Desk powers.
Framework mapping
| SecurID control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Security domains, scoped roles, separate admin accounts | AC-6, AC-6(5), AC-5 | PR.AA-05 |
| Cloud console Additional Authentication | IA-2, IA-2(1) | PR.AA-01 |
| Token record and node secret handling | IA-5, SC-12 | PR.AA-01 |
| Lockout policy | AC-7 | PR.AA-01 |
| TLS remote syslog and log masking | AU-2, AU-6, AU-9 | PR.PS-04, DE.CM-03 |
Practitioner checklist
- Confirm every Super Admin and Operations Console administrator is an individual account not linked to LDAP or Active Directory.
- Keep the Super Admin role at the top-level domain and delegate everything else through narrow roles in lower domains.
- Restrict and audit the
rsaadminpassword, and keep appliance SSH disabled outside maintenance. - Find and remove token record files and passwords stored outside AM after import.
- Use restricted agents and manual node secret delivery for sensitive systems; clear node secrets on both sides when hosts are rebuilt.
- Check the lockout policy assigned to every security domain, including new subdomains.
- Enable Additional Authentication for the Cloud Administration Console with at least two Super Admins able to complete it.
- Forward logs over TLS remote syslog, reconfigure after every restore, and alert on token assignment and emergency code events.
Standards and references
- RSA: System Administrator Accounts
- RSA: Administrative Role Overview
- RSA: Administrative Roles for the Cloud Administration Console
- RSA: Protect the Cloud Administration Console with Additional (Step-Up) Authentication
- RSA: Manage the Node Secret
- RSA: Import a Token Record File
- RSA: Lockout Policy
- RSA: Configure the Remote Syslog Host for Real-time Log Monitoring
Related NHI Mgmt Group resources: MFA Guide · Phishing-Resistant MFA Guide · RADIUS Security Guide · Break-Glass Account Guide