These ten TACACS+ security best practices start with attribution (mentioned below): one credential per human, least privilege per command, a second factor on privileged roles. Classic TACACS+ on TCP port 49 obfuscates rather than encrypts, so confine it to a hardened management network and treat shared secrets as cryptographic keys. RFC 9887 (published 9 December 2025) adds TLS 1.3 on TCP port 300 require it in procurement now. Then make the control provable and durable: command-level accounting, four alert patterns, retention to audit standards, and active-active deployment.
Picture a regional operator’s device estate: about 3,000 routers, switches and firewalls across four countries, a NOC (network operations center) running three shifts, two managed-service partners with standing access, and one shared enable password that has not changed since the last core upgrade. Nothing in that picture is unusual. Every element of it is a finding waiting for an auditor to write it down.
Most TACACS+ security advice online would not help this operator much, because most of it is a decade old and repeats at least one claim that is no longer true. The most significant change to the protocol’s transport since it was documented arrived on 9 December 2025: RFC 9887, which runs TACACS+ over TLS (Transport Layer Security) 1.3. Almost none of the currently ranking content reflects it.
Below are ten practices for securing device administration in telecom and service provider networks, what the IETF changed in December 2025, and how each maps to the frameworks operators are audited against.
The ten practices at a glance
- Retire shared enable passwords; one credential per human
- Enforce least privilege at the command level
- Add a second factor to privileged roles
- Know what TACACS+ obfuscation actually protects and what it does not
- Plan for RFC 9887: TACACS+ over TLS 1.3 on TCP port 300
- Treat the shared secret as a cryptographic key, not a password
- Capture command-level accounting, not just login events
- Stream accounting to the SIEM and alert on four specific patterns
- Retain records to the standard your auditor will apply
- Design for availability, so the control survives the incident it exists for
TACACS+ in cyber security: why device administration is the layer attackers want
TACACS+ sits in an unusual position in cyber security: it is not protecting data, it is protecting the machines that move the data. Routing tables, access control lists, traffic mirroring, VPN termination all of it is configured through the administrative plane TACACS+ governs. An attacker who compromises a subscriber account gets one subscriber’s service. An attacker who compromises device administration can reroute traffic, disable filtering, or mirror flows at will. That is not lateral movement toward a target. It is arrival.
Service provider estates sharpen the problem: thousands of devices across regions and jurisdictions, standing access for vendors and partners, business units sharing infrastructure. During an outage, losing administrative access to your own devices can do more damage than an intruder would.
The NSA’s network infrastructure security guidance treat centralized, accountable device administration as a baseline control, not an enhancement.
Make every action attributable to a person (practices 1–3)
1. Retire shared enable passwords
Start with the control that costs the least and closes the most findings. A shared enable password means every privileged action on the estate is performed by nobody: the accounting record shows the device and the command, but the identity behind it is whichever of forty people knew the string. Offboarding breaks silently a contractor who left in March can still hold privileged access in September, because rotating a credential embedded in forty runbooks is the change nobody schedules.
Central TACACS+ authentication replaces that with one credential per human, validated against the identity store the organization already runs. Every session and every command then carries a name, and offboarding becomes a single account disable rather than an estate-wide rotation. If only one practice here gets funded this quarter, fund this one; most of the other nine depend on it.
2. Enforce least privilege at the command level
Once actions are attributable, constrain them. Privilege level 15 for everyone is the device-administration equivalent of domain admin for the whole IT team: common, convenient, and indefensible in an audit. TACACS+ per-command authorization checks each command against central policy before the device runs it, which is what makes real roles – NOC operator, field technician, scoped contractor – enforceable rather than aspirational. The trade-off to plan for: per-command checks add a round trip to the server, which matters on high-latency links to remote sites and feeds directly into practice 10.
3. Add a second factor to privileged roles
Device credentials get phished, reused and written down like any others; the difference is what they unlock. A second factor means a stolen password is no longer sufficient to reach a router’s configuration mode. TACACS+ supports this cleanly because authentication is a separate exchange: the server can require an OTP (one-time passcode) or a push approval for accounts holding change-capable roles, enforced centrally rather than per device.
Be explicit about the cost. Multi-factor authentication (MFA) adds seconds to every login, and during a major incident those seconds are spent by engineers under pressure. The practical pattern is tiered enforcement: a second factor always required for change-capable and platform roles, with a documented, audited break-glass path for declared incidents (practice 10). An MFA rollout that ignores the incident case will be quietly disabled during the first bad outage, and stay that way.
Secure the transport and the secret (practices 4–6)
4. Know what TACACS+ obfuscation actually protects
Is TACACS+ traffic encrypted? Much of the internet says yes. The IETF says otherwise, and the distinction matters. TACACS+ as defined in RFC 8907 does not encrypt traffic in the modern sense: it obfuscates the packet body using an MD5-based pad derived from the shared secret. That conceals contents from a casual observer, but RFC 8907 itself states the mechanism is “best referred to as ‘obfuscation’ and not ‘encryption'”, that it offers no meaningful integrity, privacy or replay protection, and that TACACS+ must therefore be deployed only over networks that ensure the privacy and integrity of the communication.
TACACS+ obfuscation hides the packet from a casual observer. It was never designed to withstand one who is trying.
The practical consequence: classic TACACS+ on TCP port 49 must be treated as sensitive traffic on an untrusted wire. It belongs on a dedicated, access-controlled management network – a management VRF (virtual routing and forwarding instance) or an out-of-band network and should never cross shared or public segments unprotected. If a penetration-test report has flagged MD5 in your device administration path, this is what it found, and the finding is legitimate.
5. Plan for RFC 9887: TACACS+ over TLS 1.3
On 9 December 2025 the IETF published RFC 9887, a Proposed Standard that updates RFC 8907 and gives TACACS+ a modern transport. Under RFC 9887, TACACS+ runs over TLS 1.3 (RFC 8446) on a new well-known port, TCP 300. Peers must apply mutual authentication both ends present certificates and the legacy MD5-based obfuscation must not be used with TLS. The two cannot be combined.
| Classic TACACS+ (RFC 8907) | TACACS+ over TLS (RFC 9887) | |
| Port | TCP 49 | TCP 300 |
| Protection | MD5-based obfuscation of the packet body | TLS 1.3 encryption of the whole session |
| Peer authentication | Shared secret | Mutual certificate authentication |
| Status | Legacy; still the majority of deployments | Proposed Standard, published 9 December 2025 |
Now the honest part. Port 300 requires client-side support, and support in installed network devices remains limited; adoption will arrive with OS releases and refresh cycles, not with a weekend change window. What an operator should do in 2026 is threefold: keep classic TACACS+ confined to a hardened management network (practice 4), require RFC 9887 support in every server procurement and device RFP starting now, and plan certificate lifecycle operations- issuance, rotation, revocation as part of the migration, because mutual TLS makes the PKI (public key infrastructure) part of the control.
6. Treat the shared secret as a cryptographic key, not a password
Until TLS transport is universal, the shared secret is what the confidentiality of classic TACACS+ rests on, and it is the most neglected object in real deployments. Consider what a leak means: a secret exposed in a configuration backup, a Git repository, or a departed engineer’s notes lets an attacker who can reach the traffic strip the obfuscation from every packet protected by that secret – including packets captured in the past. That blast radius is why scope matters.
Handle it like key material. Alepo’s recommendation to operators: generate long, random secrets – at least 20 characters from a generator, never a word. Scope them per device or per small device group, so one leak does not expose the estate. Store them in a secrets manager with access logging, not a spreadsheet. Rotate on a defined cadence and, without exception, on staff departure or suspected exposure.
Build an audit trail that survives contact with an auditor (practices 7–9)
7. Capture command-level accounting, not just login events
A login record proves someone opened the door. It says nothing about what they did inside. TACACS+ accounting can record every command an administrator executed – user, device, command with arguments, timestamp, result – which is what centralized device administration with full session accounting is for, and that per-command record is the difference between an audit trail and an attendance sheet. For instance, when a routing change at 02:14 takes a region down, command accounting answers who, what, where and when in one query; session logs answer none of it. Configure accounting for all privileged sessions, including commands that failed authorization. Capture start and stop records, and keep device clocks synchronized with NTP (Network Time Protocol): an audit trail whose timestamps disagree is one an auditor can decline to trust.
8. Stream to the SIEM, and know the four signals worth alerting on
Records that sit on the TACACS+ server are evidence; records that reach the SIEM (security information and event management) platform are detection. Stream accounting in near real time and alert on the four patterns that characterize attacks on device administration:
| Signal | What it looks like in TACACS+ records | Alert on |
| Brute force | Bursts of failed authentications for one account, often walked across many devices | Failure count per account/source above a short-window threshold |
| Credential stuffing | Failures spread across many accounts from one source, each tried once or twice | Distinct-accounts-per-source above threshold |
| Privilege escalation | A valid, authenticated user repeatedly denied commands above their role; enable attempts from read-only accounts | Repeated authorization denials per user in a short window |
| Service-account misuse | An automation account opening an interactive session, or appearing from a new source address or outside its normal hours | Any interactive use of a non-interactive account |
Two of the four – escalation and service-account misuse – involve valid credentials, so they defeat perimeter controls and appear only in the accounting stream. A contractor account that normally runs show commands from one jump host starts issuing configuration commands at 03:00 from a new address: every individual record looks legitimate, and only the pattern is wrong. Pattern-level detection across an estate this size is machine work, and it sits on top of the accounting stream these practices produce – see consolidating AAA protocols on one platform.
9. Retain records to the standard your auditor will apply
Retention is where good logging programs quietly fail. PCI DSS (Payment Card Industry Data Security Standard) v4.0 Requirement 10 expects twelve months of audit log history with three months immediately available; other frameworks and national telecom regulations set their own floors, and the EU’s NIS2 Directive sets its own obligations for European operators. Set retention to the strictest standard that applies to you, not the log platform’s default. Integrity matters as much as duration: accounting records should be written to storage the administrators being audited cannot alter, because a trail the subject of the audit can edit proves nothing. Document the retention policy and test retrieval before an auditor does.
Design so the control survives the incident (practice 10)
10. Availability is a security property here
Every practice above routes device access through the TACACS+ service, which concentrates a new risk: if that service goes down during a network incident, engineers cannot reach the devices they need to fix, at the moment they need them most. If the service is unreachable, devices fall back to whatever local authentication the operator configured – which is why fallback must be designed rather than inherited.
Two design rules follow. Deploy the TACACS+ service active-active across at least two sites, so the loss of one site or the network partition that caused the incident – leaves authorization decisions flowing from the other. And define fallback deliberately: a local emergency account per device, credentials held in a secrets manager under break-glass procedure, every use alarmed and reviewed afterward. Fallback that quietly reverts the estate to shared local passwords undoes practices 1 through 3 at the first sign of trouble.
Mapping these practices to the frameworks you are audited against
Compliance leads need control references, not assurances. The mapping below connects the ten practices to the four frameworks most often applied to operator device estates. European operators should also expect NIS2-derived national requirements, and utility-adjacent networks will meet their cousins in NERC CIP.
| Practices | NIST SP 800-53 Rev. 5 | CIS Controls v8 | PCI DSS v4.0 | ISO/IEC 27001:2022 Annex A |
| 1–3 · Identity and least privilege | AC-2, AC-6, IA-2 | 5, 6 | Req 7, 8 | 5.15, 5.18 |
| 4–6 · Transport and secret protection | SC-8, IA-5 | 3.10 | Req 2.2.7 | 8.24 |
| 7–9 · Accounting and audit trail | AU-2, AU-3, AU-12 | 8 | Req 10 | 8.15 |
| 10 · Availability of the control | CP-2, CP-10 | — | — | 8.14 |
Control references are indicative starting points for your own mapping exercise, not a compliance certification. Confirm the control set that applies to your scope with your auditor.
One caution: no product makes an operator compliant. What a TACACS+ server supplies is evidence attributable identities, enforced authorization, complete accounting records and evidence is what auditors actually ask for. Any vendor who phrases it more generously than that is describing their marketing, not your audit. For how Alepo approaches these frameworks in its own operations, see our security and compliance posture.
Where this sits alongside subscriber access
TACACS+ secures the engineers who run the network. Subscriber authentication is a different problem with different protocols; the full comparison lives in our guide to how TACACS+ differs from RADIUS and Diameter in Communications Service Provider (CSP) environments.
| TACACS+ | RADIUS | |
| Population | Network administrators | Subscribers and endpoints |
| Job | Device administration | Network access |
| Authorization | Separate, per command | Combined with authentication |
| Transport | TCP 49 / TCP 300 (TLS) | UDP 1812/1813 |
| Accounting | Command-level audit trail | Usage and billing records |
Reviewing your own estate against these ten practices? Walk through your device-administration setup with an AAA (authentication, authorization, and accounting) specialist: bring your current architecture and the findings you are working from. Book a demo
FAQs
Q1. Is TACACS+ traffic encrypted?
Not under the original protocol. RFC 8907 defines an MD5-based obfuscation of the packet body – the RFC itself calls it obfuscation, not encryption, and states it offers no meaningful integrity, privacy or replay protection. Real encryption arrived with RFC 9887 in December 2025, which runs TACACS+ over TLS 1.3 on TCP port 300.
Q2. What is RFC 9887?
RFC 9887 is an IETF Proposed Standard, published 9 December 2025, that runs TACACS+ over TLS 1.3. It updates RFC 8907, requires mutual certificate authentication between device and server, forbids the legacy obfuscation on TLS connections, and uses TCP port 300. Operators procuring TACACS+ servers or network devices should require support for it now.
Q3. Why does TACACS+ over TLS use a different port?
RFC 9887 separates TLS-protected TACACS+ (TCP 300) from classic TACACS+ (TCP 49) so a connection’s protection is unambiguous from its port: no downgrade ambiguity, and firewalls can police the two services separately during migration. Devices supporting both can run them side by side while the estate transitions.
Q4. How long should a TACACS+ shared secret be?
Treat it as key material: at least 20 random characters from a generator, unique per device or small device group, stored in a secrets manager rather than a spreadsheet or config repository. Rotate on a defined schedule and immediately on staff departure or suspected exposure. Length is the cheap part; scope and rotation are what limit a leak.
Q5. Can you use MFA with TACACS+?
Yes. TACACS+ authentication is a separate, multi-round exchange, so the server can require a one-time passcode or push approval, typically enforced for change-capable and platform roles. Plan the incident case deliberately: a second factor slows logins during outages, so pair it with an audited break-glass path rather than letting teams disable it under pressure.
Q6. What should TACACS+ accounting logs capture for an audit?
Per-command records: the authenticated user, the device, the exact command with arguments, the timestamp, and whether it was permitted or denied, plus session start and stop records. Auditors ask for attribution, completeness across every privileged session, integrity that administrators cannot alter, and retrievability within the retention window.
Q7. How do you detect an attack on device administration?
Watch the accounting and authentication stream for four patterns: failed-authentication bursts against one account (brute force), failures across many accounts from one source (credential stuffing), repeated authorization denials for a valid user (escalation attempts), and interactive or off-hours use of service accounts. The last two use valid credentials, so only the pattern gives them away.
Q8. Does TACACS+ make us PCI DSS compliant?
No. No product makes anyone compliant. TACACS+ supplies evidence toward specific requirements: individual authentication (Requirement 8), role-based restriction of access (Requirement 7), and logged administrative activity (Requirement 10). An assessor evaluates the whole environment. Ask a vendor what evidence its product produces, not whether it delivers compliance.
Q9. Should we upgrade to TACACS+ over TLS now?
Adopt it where your devices and server support it; most installed equipment does not yet, and that is normal nine months after publication. What every operator should do now: require RFC 9887 support in procurement, keep classic TACACS+ on a hardened management network in the meantime, and plan the certificate operations mutual TLS will need.
