Arista switches in data centres are managed through more channels than most teams track: SSH, eAPI over HTTPS, gNMI, the CloudVision streaming agent and a Linux shell underneath it all, and each one is a way in if left at defaults. Data centre fabrics are automated, so the most powerful credentials on an Arista estate often belong to automation tools and CloudVision rather than people. This guide covers EOS authentication and role-based access, the root and enable accounts, eAPI and gNMI hardening, CloudVision TerminAttr authentication, the control-plane ACL and CoPP, TLS profiles, logging and detection. It is written for network engineers and security teams running Arista EOS. General principles that apply to every vendor are in the Network Device Management Plane Hardening Guide; this page stays on EOS.
This is an independent guide from NHI Mgmt Group, based on Arista's public documentation as of November 2026. It is not sponsored or reviewed by Arista. Product features change, so confirm settings against Arista's current documentation.
Key takeaways
- Centralise authentication with TACACS+ or RADIUS. Use
aaa authentication login default group ...with local fallback, and map users to EOS roles (network-admin,network-operatoror custom roles) rather than sharing local accounts. - Disable the root shell account.
no aaa rootremoves direct root login; keep the enable password hashed with SHA-512. - Treat eAPI, gNMI and CloudVision as privileged APIs. HTTPS only, an SSL profile, a management VRF and a standard ACL on each, and never set TerminAttr's
disable_aaaoption in production. - Replace the default control-plane ACL.
default-control-plane-aclis read-only and permits management protocols such as SSH, Telnet, HTTP and SNMP from any source, so clone it, restrict sources and apply it undersystem control-plane. - Patch from Arista's advisories. Arista publishes numbered security advisories with RSS, CSAF and email feeds; apply EOS security updates promptly.
How identity and access work in Arista EOS
EOS authenticates and authorises every management session through its AAA framework, whatever the channel. That includes the CLI over SSH or console and API calls over eAPI. Sources can be local accounts, TACACS+, RADIUS or LDAP, organised in server groups.
| Element | EOS command or object | Hardening point |
|---|---|---|
| Login authentication | aaa authentication login default group TACACS1 local | Central first, local only as fallback for outages |
| Command authorisation | aaa authorization exec default group ..., command authorisation | Authorise per command for administrators so TACACS+ can deny dangerous commands |
| Accounting | aaa accounting exec and commands to the TACACS+ group | Every command recorded centrally |
| Server groups | aaa group server tacacs+, aaa group server radius | Servers reached through the management VRF; RADIUS over TLS with an SSL profile where supported |
| Local users | username <name> secret ... | Passwords stored as SHA-512 hashes; one break-glass account, vaulted |
| No-password logins | Console only by default; aaa authentication policy local allow-nopassword-remote-login changes this | Never enable remote no-password login; Arista advises against it |
| Roles | network-admin (all commands), network-operator (EXEC only), custom role with ordered permit and deny rules | Default users to operator; build custom roles for automation |
| Remote role assignment | RADIUS Arista-AVPair shell:roles= and shell:priv-lvl= (0 to 15) | Assign roles from the AAA server so access follows group membership |
Check role definitions with show users roles and server health with show tacacs and show radius. Use tacacs-server host ... single-connection to multiplex sessions, and set a short timeout so fallback to local accounts happens quickly during an outage. See the AAA Security Guide.
Admin roles and privileged access
- Root account: EOS runs on Linux.
aaa root secretsets a root password,aaa root nopasswordremoves it, andno aaa rootdisables the account. Arista's own validated designs generateno aaa root. Disable it and reach the shell, where needed, through thebashcommand under AAA authorisation and accounting. - Enable password: set
enable password sha512 ...so the stored value is a hash. With role-based authorisation from TACACS+ the enable step matters less, but an unset enable password is a finding in most audits. - Password encoding: keys and passwords in
running-configare stored encrypted or hashed; theencrypt-typevalue (0 clear text, 5 hashed, 7 encrypted keys) controls how input is read. Type 7 is reversible, so treat a config backup containing TACACS+ and RADIUS keys as sensitive. - Break-glass: one local
network-adminaccount per device with a unique vaulted password, alerting on every use. - Bash access: limit the
bashcommand to a small custom role; changes made in the Linux shell bypass the CLI command authorisation that TACACS+ provides.
Integrations, API tokens and service accounts
Automation is where most privileged activity happens on an Arista fabric. Each integration needs its own identity, transport protection and network restriction.
| Interface | Configuration | Harden by |
|---|---|---|
| eAPI (JSON-RPC over HTTP) | management api http-commands, protocol https, no shutdown, per-VRF enablement | HTTPS only (never protocol http); an SSL profile with your own certificate; enable only in the management VRF with a standard ACL; session timeout lower than the 1,440 minute default; a dedicated automation account with a custom role |
| eAPI unix socket | protocol unix-socket | Enable only when on-box scripts need it |
| gNMI / OpenConfig | management api gnmi, transport grpc <name> (default TCP 6030) | ssl profile, ip access-group, vrf, and authorization requests so each RPC passes AAA authorisation |
| CloudVision (TerminAttr) | TerminAttr daemon streaming to CloudVision (TCP 9910 on-premises, 443 for CloudVision as a Service) | Certificate or token authentication; obscure the key file; CloudVision-only VRF; never set disable_aaa; consider gNMI read-only mode where config push is not used |
| SSH | management ssh | Restricted cipher, MAC and key exchange lists, fips restrictions where required, idle timeout, connection limits and an ingress ACL per VRF |
- CloudVision authority: CloudVision can push configuration to every device it manages. Arista's validated design schema warns that setting TerminAttr's
disable_aaameans all commands pushed from CloudVision are applied directly without authorisation. Keep AAA on so CloudVision changes are authorised and accounted, and protect CloudVision administrator accounts with SSO and MFA as you would a domain controller. - Mutual TLS: EOS supports mTLS for gRPC, RESTCONF and eAPI. By default only certificates signed by Arista's CA are trusted, so install your own CA with
trust certificatein the SSL profile before relying on client certificates. - Automation credentials: Ansible, Nornir and AVD pipelines hold credentials for every switch. Store them in a secrets manager, give pipelines a custom role rather than
network-adminwhere possible, and rotate on staff changes. See the Secrets Management Guide.
Hardening baseline
Control-plane ACL and CoPP
Arista's open management documentation explains that the default control-plane ACL cannot be modified. It contains broad entries, including permit tcp any any eq ssh telnet www snmp bgp https msdp ldp netconf-ssh gnmi. The supported approach is to read it with show ip access-lists default-control-plane-acl, copy it into a new ACL, tighten sources, and apply it under system control-plane with ip access-group <acl> in (or ip access-group <acl> vrf <vrf> in) on EOS 4.23 and later. Keep the routing protocol, BFD and MLAG entries the fabric needs and restrict management protocols to your management subnets. Control-plane policing complements the ACL: policy-map type copp copp-system-policy rate-limits traffic classes punted to the CPU. The DISA Arista MLS EOS router STIG rates "restrict traffic destined to itself" as high severity.
Baseline settings
| Area | Setting | Recommended state |
|---|---|---|
| Root | no aaa root | Disabled |
| Remote no-password login | allow-nopassword-remote-login | Not configured |
| Telnet and HTTP | management telnet, eAPI protocol http | Shut down |
| TLS | management security, ssl profile with tls versions 1.2 or 1.3 and a cipher-list | Applied to eAPI, gNMI, RADIUS and syslog over TLS |
| Certificates | security pki key generate, signing-request, crl | Device certificates from your CA, CRLs loaded |
| Control plane | system control-plane custom ACL; copp-system-policy | Management sources restricted; CoPP reviewed |
| Management VRF | Management services, AAA and logging in a dedicated VRF | Management traffic separated from the data plane |
| Logging | logging vrf MGMT host ... protocol tls ssl-profile ..., logging format rfc5424, logging source-interface | Central, encrypted, consistent format |
| SNMP | SNMPv3 with authentication and privacy; no default communities | Read-only, ACL restricted |
| FIPS | fips restrictions on SSH and SSL profiles | Where policy requires FIPS-approved algorithms |
Rolling out hardening across a fabric
- Baseline: export running configurations and record which management services, VRFs and ACLs each device uses. Flag devices with
protocol http, Telnet,aaa rootset or TerminAttrdisable_aaa. - Model in code: express the baseline in your configuration generator (for example Arista AVD data models) so every device gets the same settings and drift is visible.
- Lab first: test the custom control-plane ACL in a lab or digital twin with all routing protocols, MLAG and BFD up; a missing entry can drop adjacencies.
- Pilot a pair of leaves: apply ACL, AAA and TLS changes to one MLAG pair, watch logs and ACL counters, then roll out by pod.
- Use configuration sessions: stage changes in an EOS configuration session with a commit timer so the change rolls back automatically if you lose access.
- Rollback: keep the previous ACL in place unapplied and the console path tested, so reverting is one command.
Choosing an approach for your estate
- Small estates (a few switches, CLI managed): prioritise TACACS+ or RADIUS with accounting,
no aaa root, eAPI off unless used, Telnet and HTTP off, and a custom control-plane ACL. CloudVision and gNMI may not be present at all, which removes whole attack paths. - Automated fabrics (AVD, CloudVision, gNMI telemetry): the automation platform is the crown jewel. Separate read-only telemetry identities from configuration-push identities, use certificates for TerminAttr and gNMI clients, and gate configuration pushes through change review in the pipeline rather than ad hoc CloudVision edits.
- TACACS+ or RADIUS: TACACS+ gives per-command authorisation and accounting, which suits administrator access; RADIUS fits where a NAC platform already issues roles through the Arista-AVPair attribute and can run over TLS with an SSL profile.
- Regulated environments: apply
fips restrictionson SSH and SSL profiles and align the baseline with the DISA STIG for Arista MLS EOS, documenting any deviation.
Logging and detection
| Signal | Source | Why it matters |
|---|---|---|
| Command accounting | TACACS+ accounting | Who ran what, including configuration and bash commands |
| Login failures and local account use | Syslog AAA messages | Brute force (T1110) and break-glass use outside incidents |
| Configuration changes | Syslog, CloudVision change records, config backups | Unexpected changes to AAA, ACLs or management services (T1556 Modify Authentication Process) |
| Control-plane ACL hits | ACL counters on the custom control-plane ACL | Management access attempts from unexpected sources |
| Configuration exports | AAA accounting, API logs | Bulk config retrieval (T1602.002 Network Device Configuration Dump) exposes type 7 keys |
| Streaming telemetry | TerminAttr log streaming (/var/log/messages by default) | A second, independent copy of device logs in CloudVision |
Send logs over TLS to a collector in the management VRF and alert when a device stops logging. See the Network Device Syslog and Configuration Change Detection Guide.
Metrics that show it is working:
- Percentage of devices with a custom control-plane ACL applied in every VRF.
- Percentage of devices with
no aaa root, no Telnet and eAPI HTTPS only. - Count of local account logins outside declared incidents (target zero).
- Days from an Arista security advisory to remediation on affected devices.
- Percentage of devices whose running configuration matches the generated baseline.
Common misconfigurations
- Relying on the default control-plane ACL, which permits SSH, Telnet, HTTP, HTTPS and SNMP from any source in its read-only form.
- eAPI enabled with
protocol httpor in the default VRF without an ACL, sending credentials in clear text across the fabric. - TerminAttr with
disable_aaaset during onboarding and never removed, so CloudVision changes bypass authorisation and accounting. - A shared
adminaccount used by people and automation alike, so accounting cannot tell who did what. - Configuration backups stored openly while they contain reversible type 7 TACACS+ and RADIUS keys.
- Advisories missed because nobody subscribed to Arista's RSS, CSAF or email feeds. See the Vulnerability Management for Network Devices Guide.
Framework mapping
| Control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK |
|---|---|---|---|
| Central AAA and roles | IA-2, AC-2, AC-6 | PR.AA-01, PR.AA-05 | T1078 |
| Control-plane ACL and CoPP | SC-7, SC-5, AC-17 | PR.IR-01 | T1498 |
| TLS profiles and SSH crypto | SC-8, SC-13 | PR.AA-03 | T1040 |
| Baseline and drift control | CM-6, CM-7 | PR.PS-01 | T1556 |
| Logging and accounting | AU-2, AU-6, AU-9 | PR.PS-04, DE.CM-09 | T1602.002 |
| Advisory-driven patching | SI-2 | PR.PS-02 | T1190 |
Practitioner checklist
- Configure TACACS+ or RADIUS login, authorisation and accounting through the management VRF, with local fallback only.
- Assign users to
network-operatoror custom roles by default; restrictnetwork-adminandbash. - Set
no aaa rootand a SHA-512 enable password; vault one break-glass account per device. - Run eAPI and gNMI over HTTPS or TLS with an SSL profile, a management VRF and a standard ACL; shut down HTTP and Telnet.
- Authenticate TerminAttr with certificates or tokens and remove any
disable_aaasetting. - Clone the default control-plane ACL, restrict management sources and apply it under
system control-planefor each VRF. - Review
copp-system-policyrates for your platform and traffic. - Send syslog over TLS in RFC 5424 format and alert on silent devices.
- Subscribe to Arista security advisories and track remediation time.
Standards and references
- Arista: EOS User Manual, User Security
- Arista: EOS User Manual, Control Plane Security
- Arista: Securing Management Services (Open Management)
- Arista: OpenConfig Configuration (Open Management)
- Arista: Security Advisories
- DISA Arista MLS EOS 4.X Router STIG, restrict traffic destined to itself (third-party copy on STIG Viewer; official STIGs are on cyber.mil)
- MITRE ATT&CK: Network Device Configuration Dump
Related NHI Mgmt Group resources: Network Device Management Plane Hardening Guide · AAA Security Guide · Network Device Syslog and Configuration Change Detection Guide · Vulnerability Management for Network Devices Guide