TACACS+ does not make an organization SOC 2 (System and Organization Controls 2) compliant. No product does. What TACACS+ command accounting does is produce SOC 2 access control evidence for a specific set of Trust Services Criteria. That evidence concentrates in the Security category’s logical access (CC6), system operations (CC7), and change management (CC8) criteria, with a supporting role under Availability. This article maps each criterion, lists the artifacts auditors ask for, and points to Alepo’s existing posts for the other frameworks, so that ground is covered once.
If you are preparing SOC 2 access control evidence for an operator or enterprise network estate, the routers, switches, and firewalls your administrators log into are in scope. Sooner or later the auditor will ask a plain question about them: who ran what command, on which device, when, and who approved that person having the ability to do it. TACACS+ (Terminal Access Controller Access-Control System Plus) is the protocol most operators run for device administration, and it is built to answer that question. This article shows where its evidence lands in the SOC 2 framework and where it does not.
What does SOC 2 require for access control?
SOC 2 is an attestation framework from the American Institute of Certified Public Accountants (AICPA). Attestation means an independent auditor examines the controls you designed, tests whether they meet the Trust Services Criteria you put in scope, and issues an opinion. There is no fixed checklist of required controls; you choose the controls, and the auditor judges whether they satisfy the criteria. The current criteria are the 2017 Trust Services Criteria with Revised Points of Focus (2022).
The criteria sit in five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The Security category is included in every SOC 2 examination; the other four are added when they are relevant to the service under review. Security is made up of the common criteria, numbered CC1 through CC9. The two series that matter most for network device administration are CC6 (Logical and Physical Access Controls) and CC7 (System Operations), with CC8 (Change Management) close behind. The other categories have their own series; Availability criteria, for example, are numbered A1.1 through A1.3.
Two more definitions matter for everything that follows. A Type I report assesses whether controls are suitably designed at a point in time. A Type II report assesses design and operating effectiveness across an observation period, commonly six to twelve months. Type II is what enterprise customers and procurement teams usually ask for. It is also where accounting logs matter most, because the auditor samples activity across the whole period and a single day’s configuration screenshot will not cover it.
Each criterion also comes with “points of focus.” These are illustrative guidance and are not themselves required; an auditor uses them to reason about whether your control addresses the criterion. The mapping below works at the criterion level for that reason.
Where does TACACS+ evidence map to each Trust Services Criterion?
The short version, by category:
| SOC 2 category | What TACACS+ evidences | Strength of the evidence |
| Security | Centralized authentication, per-command authorization by role, per-command accounting records, monitoring of administrative sessions | Primary. This is where TACACS+ evidence belongs. |
| Availability | Redundant authentication service so device administration survives a server or site failure | Supporting. Covers the authentication service itself, not the wider system. |
| Confidentiality | Protection of administrative credentials and sessions in transit | Partial. Depends on the transport you run (see the note under CC6.7). |
| Processing Integrity | Little direct relevance unless network devices are part of the processing system under examination | Indirect. Cite only if the devices are in the processing path. |
| Privacy | TACACS+ governs administrator access, not personal information handling | None. Do not cite it here. |
The criterion-level mapping is the part to hand to your auditor. Criterion descriptions below are paraphrased; your own compliance team should confirm each against the AICPA text.
| Criterion | What it asks for (paraphrased) | What TACACS+ provides | Evidence artifact |
| CC6.1 | Logical access security software and architecture over protected information assets | A single authentication and authorization point in front of every managed device, backed by your directory | Architecture diagram; device configurations showing TACACS+ as the authentication method; server configuration |
| CC6.2 | Users are registered and authorized before credentials are issued; credentials are removed when access ends | Administrator identity comes from your LDAP (Lightweight Directory Access Protocol) or Active Directory user directory, so onboarding and offboarding in the directory propagate to every device at once | Directory-to-TACACS+ group mapping; accounting records showing a departed user’s last session and no sessions after their departure date |
| CC6.3 | Access is granted, modified and removed based on role, with least privilege and segregation of duties | Command authorization by role: each role is permitted a defined command set and denied everything else | Role-to-command matrix exported from the server; authorization deny records showing out-of-role commands rejected |
| CC6.6 | Logical access is protected against threats from outside the system boundary | Authentication is enforced for every management session, including remote ones, with no local fallback in normal operation | Failed-authentication records; device configuration showing local accounts restricted to console or emergency use |
| CC6.7 | Information is restricted and protected during transmission | Protection of the administrative session between device and server (see transport note below) | Server configuration showing the transport in use; segmentation of the management network |
| CC7.2 | System components are monitored for anomalies that may indicate malicious acts or errors | A complete, centralized command trail feeding your security information and event management (SIEM) system, so an unusual command or off-hours session is visible | SIEM ingestion configuration; sample alerts triggered from TACACS+ accounting; retention policy |
| CC7.3 | Security events are evaluated to determine whether they are incidents | Per-command records with user, device, timestamp and result, so an investigator can reconstruct exactly what an administrator did | Sample incident ticket with the accounting records used to scope it |
| CC8.1 | Changes to infrastructure are authorized, tested, approved and implemented under control | Command accounting is the proof that a configuration change on a network device was made by an authorized person, at a recorded time, within an approved window | Accounting records tied to change tickets; authorization records for configuration-mode commands |
| A1.2, A1.3 | Recovery infrastructure is implemented, operated, and monitored (A1.2); recovery procedures are tested (A1.3) | Redundant TACACS+ servers across sites so administrators are not locked out by a single server or site failure | High-availability design; failover test records dated within the observation period |
Control references are indicative starting points for your own mapping exercise, not a compliance certification. Confirm the criteria that apply to your scope with your auditor.
Two rows deserve a note.
- On CC6.7 and the transport: Classic TACACS+ on TCP (Transmission Control Protocol) port 49 protects the packet body with an MD5 (Message Digest 5)-based mechanism. RFC 8907 (Internet Engineering Task Force, September 2020) itself describes that mechanism as obfuscation and says it should not be called encryption. RFC 9887 (December 2025) defines TACACS+ over Transport Layer Security (TLS) 1.3 on TCP port 300 and obsoletes the obfuscation mechanism. If you cite TACACS+ under CC6.7, be precise about which transport you run. If it is the classic one, cite the management-network segmentation that RFC 8907 requires alongside it. An auditor who reads RFCs will check. Our post on RFC 8907 and RFC 9887 covers the difference in full.
- On CC6.3 and role design: The evidence here is only as good as the roles behind it. If every administrator sits in one all-commands group, the accounting trail still exists, but it evidences nothing about least privilege. The role structure itself is covered in our post on role-based privilege levels. That post also maps the same control to NIST (National Institute of Standards and Technology) SP 800-53, CIS (Center for Internet Security) Controls v8, PCI DSS (Payment Card Industry Data Security Standard) v4.0, and ISO/IEC 27001:2022.
What do SOC 2 auditors actually ask to see?
Auditors rarely ask “do you use TACACS+.” They ask for artifacts that demonstrate a control operated throughout the period. For network device administration, the request list usually looks like this.
- A population and a sample: These are the auditor’s terms for the full set of in-scope items and the subset they test. The population here is the list of in-scope network devices, with evidence that each one authenticates against the central server. Expect to export a device inventory from the TACACS+ server and have a sample of devices pulled for configuration inspection. Expect a specific question about the local emergency account on each device, too: who holds the password, where it is stored, and whether its use appears in the logs.
- The access matrix: Who is in which role, and what each role may run. Export it from the server. A matrix assembled by hand in a spreadsheet the week before fieldwork invites an immediate follow-up question about how you know it is accurate.
- Provisioning and deprovisioning evidence: For a sample of new hires and departures during the period, show the directory change and the corresponding presence or absence of sessions in the accounting log. When the TACACS+ server takes identity from your directory, one directory record usually closes both questions.
- Command accounting records, across the period: For a Type II report this is the central artifact. The auditor may pick dates at random across the observation window and ask for the accounting records for a given device or administrator. This is why retention matters: records must exist for the whole period, be stored centrally, be time-synchronized, and be protected from modification by the same administrators they record. The mechanics of the records themselves, including start, stop, and watchdog types and the cmd and cmd-arg fields, are covered in TACACS+ accounting and audit log retention.
- Monitoring evidence: Alerts that fired from the accounting stream during the period, and what happened next. CC7.2 asks whether you monitor, so a complete log with no alerts or reviews attached to it proves retention and little else.
- Failover evidence: If you cite A1.2 and A1.3, expect to show dated records of a failover test during the period. A high-availability design document on its own covers A1.2 and leaves A1.3 open.
One practical habit shortens every one of these requests: keep a standing evidence folder, refreshed monthly during the observation period, with exports named by criterion. It also shortens fieldwork, because the auditor’s follow-up questions arrive while the exports are still current and the people who produced them still remember how.
Does TACACS+ make you SOC 2 compliant?
No, and a vendor claim to the contrary is a reason to read the rest of its material more carefully. SOC 2 is an opinion on your system of controls as a whole. TACACS+ contributes to roughly ten criteria out of the full set, and only when it is deployed with defined roles, enforced retention, and active monitoring around it. A well-run TACACS+ deployment is strong, sample-friendly evidence for network device access control. The attestation itself rests on everything else you do as well.
How does this fit alongside ISO 27001 and PCI DSS?
The frameworks overlap in what they want from network device administration; they differ in how they are structured. SOC 2 is organized around criteria and an auditor’s opinion. ISO/IEC 27001:2022 is organized around Annex A controls and a management system. PCI DSS v4.0 is organized around numbered requirements for the cardholder data environment. The same TACACS+ accounting record can serve all three, but the citation differs.
Those mappings already exist on this site, so use them as companions to this article. For ISO/IEC 27001:2022 Annex A 5.15 and 5.18, NIST SP 800-53 AC-2 and AC-6, CIS Controls v8 Control 6, and PCI DSS v4.0 Requirement 7, see the role-based privilege levels post.
If you need a server that produces this evidence by default, with role-based command authorization, centralized accounting, directory integration, and active-active redundancy, see Alepo’s TACACS+ server. The TACACS+ datasheet (PDF) has the command-authorization and accounting detail behind those capabilities. If you are preparing for a SOC 2 audit now and want to walk through your device-administration evidence with an Alepo AAA (Authentication, Authorization, and Accounting) specialist, book a demo.
FAQs
Q1. Does TACACS+ make us SOC 2 compliant?
No. SOC 2 is an auditor’s opinion on your whole system of controls against the Trust Services Criteria you place in scope. No single product delivers that. TACACS+ provides specific evidence for network device access control that auditors can sample across the period, chiefly under the Security criteria CC6, CC7, and CC8. It does so only when deployed with defined roles, central log retention, and active monitoring.
Q2. Which SOC 2 Trust Services Criteria does TACACS+ evidence support?
TACACS+ evidence supports primarily the Security category: CC6.1, CC6.2, CC6.3, CC6.6, and CC6.7 for logical access, CC7.2 and CC7.3 for monitoring and event evaluation, and CC8.1 for change management. A redundant, tested TACACS+ deployment also supports Availability criteria A1.2 and A1.3. It offers little for Processing Integrity and nothing for Privacy, and you should not cite it there.
Q3. What SOC 2 audit evidence can TACACS+ accounting logs provide?
Per-command records showing which administrator ran which command on which device, with timestamps and results, across the full observation period. Auditors use these to sample activity on random dates, confirm de-provisioned users had no later sessions, tie configuration changes to change tickets, and verify that monitoring alerts were generated and handled. Retention, central storage, and time synchronization are what make the records acceptable.
Q4. Is TACACS+ accounting sufficient on its own for a SOC 2 Type II audit?
No. A Type II report covers control design and operating effectiveness across six to twelve months and spans many domains beyond network administration. TACACS+ accounting covers one slice: privileged access to network devices. It must be paired with role design, directory-driven provisioning, retention, and monitoring, and it says nothing about your applications, endpoints, vendors, or people controls.
Q5. How does TACACS+ compliance evidence relate to ISO 27001 or PCI DSS?
The same accounting records serve all three frameworks; only the citation changes. SOC 2 cites Trust Services Criteria. ISO/IEC 27001:2022 cites Annex A controls such as 5.15 and 5.18. PCI DSS v4.0 cites numbered requirements such as Requirement 7 for access and Requirement 10 for logging. Alepo’s privilege-levels and accounting posts map those two frameworks in control-level detail.
