Strong authentication is necessary. It is not always sufficient.
By Terry Burton, Director of Security, InkBridge Networks
What is AAA in information security?
Authentication, Authorisation, and Accounting (AAA) is the security framework that controls who gets onto your network, what they can do once they're there, and what gets logged while they are.
Authentication verifies identity. Is this person or device who they claim to be? It's the check at the door.
Authorisation determines access rights. Once authenticated, what is this user allowed to do? Which systems, files, and resources are within their scope?
Accounting creates the audit trail. What did they do, when, and for how long? This is the data that enables compliance reporting, anomaly detection, and post-incident forensics.
Together, these three functions form the backbone of network access control. For a deeper look at each component individually, see our articles on Authentication, Authorisation, and Accounting.
The most common protocol implementing AAA in enterprise networks is RADIUS (Remote Authentication Dial-In User Service). When a user connects to a corporate Wi-Fi network or VPN, RADIUS is almost certainly handling the authentication handshake in the background.
Most organisations running enterprise networks have some form of AAA in place. The problem is what they assume that means.
The front door and the back doors
In my experience, when organisations suffer breaches, it is rarely because their primary AAA stack was broken. It is usually because something adjacent was weak.
My way of putting it: attackers do not go after the control you are proud of. They go after the seams between systems - the gaffer tape and string holding everything together that no one is particularly proud of.
Consider a common enterprise setup. General staff authenticate via a well-configured RADIUS system with multi-factor authentication (MFA) and solid policies. But vendors -the HVAC contractor, the fire alarm maintenance firm, the software supplier doing their annual update - may have their own access methods that operate entirely outside that system. Vendor tooling is often a contractual requirement, and access is set up once and rarely reviewed.
This wouldn't be a problem if those vendor access pathways led only to isolated network segments. Often, they don't. Very often, enterprises run a flat network in which all these access points - staff, vendor, IoT, and infrastructure - coexist without meaningful separation. If an attacker compromises a vendor with careless password hygiene, lateral movement from the HVAC segment to the ERP database may be trivially easy.
AAA security architecture, then, is about more than the strength of your authentication mechanism. It is about the assumptions you are making about what happens after authentication succeeds.
Three common gaps in AAA security architecture
1. VIP exceptionalism undermines the system for everyone
In many organisations I have worked with, the most senior accounts carry the weakest controls:
- MFA gets disabled for executives who find it inconvenient.
- Monitoring gets softened to avoid embarrassment.
- Data loss prevention tools get switched off so that somebody can stream a sporting event.
I mean that last one literally. I worked with an organisation that had data loss prevention (DLP) controls in place - the kind that screen outgoing email for sensitive content and block access to websites outside expected use. Sensible stuff. A senior executive needed to watch the Grand Prix. The DLP controls and web filtering were turned off for the duration of the tournament.
What’s most striking is that they did not have full assurance that a previous cyber
incident had been fully mitigated. Yet the controls that would have stopped data from trivially walking out the door (the ones that were there precisely for that scenario) came down anyway, because a senior person wanted to stream Silverstone.
There is also a well-documented case involving a government organisation's cloud email service where MFA had been largely successfully piloted - then not implemented, even for highly sensitive accounts, due to negative feedback from a handful of VIPs.
Attackers used a technique called password spraying: rather than hammering one account with many password attempts (which triggers lockouts), they applied a small number of common passwords across every account simultaneously. Controls triggered across the board, MFA was disabled entirely during the chaos, and around 100 accounts were compromised.
Security that bends for status creates predictable, high-value entry points. If the most powerful accounts in an organisation are also the least protected, that is where a motivated attacker will aim.
2. Helpdesk over-privileging
Here is a troublesome structural reality I encounter regularly: the most junior person in the IT department (often on a temporary or zero-hours contract) may have the greatest effective privilege in the building.
Why? Because helpdesk roles typically carry tools that can reset any password, unlock or modify MFA factors, and indirectly assume administrative authority over systems. If a helpdesk analyst can reset a domain administrator's password, they effectively are a domain administrator, at least for the duration of that reset window.
This creates an obvious social engineering target. Junior staff, often underpaid and with no particular loyalty to the organisation, may be susceptible to bribery, manipulation, or simple carelessness. Casual staff working help desks over summer months, for example, may not fully appreciate the exposure their access level creates. Some would not be able to turn down a bribe, reasoning that they are nobody important. The damage that can be done from a helpdesk login would suggest otherwise.
Highly privileged account management should be kept out of general helpdesk scope. This is a design decision, and it is one that many organisations have never consciously made.
3. Flat networks and the false confidence of strong AAA
Strong authentication at login time is not the same as strong security after login. Once an attacker has a foothold on a flat network, the AAA system has done its job and stepped aside.
Attackers do not interact with compromised networks the way users do. Carefully designed web applications, role-based access controls, and business logic are not what an attacker with network access is working through. They are going directly to APIs, databases, and infrastructure pathways. They are looking for exposed services, misconfigured systems, and automation tokens. The attacker's experience of a network looks nothing like the user experience that was designed for legitimate staff.
If an ERP database sits in the same VLAN as an HVAC controller, no AAA system can protect it after the perimeter has been crossed. This is the fundamental limitation of treating AAA as a complete security strategy rather than one layer in a defence-in-depth architecture.
When AAA upgrades go wrong
Organisations often invest heavily in upgrading their authentication mechanisms. What they invest in less reliably is the operational discipline to sustain those upgrades.
I have seen a Wi-Fi network upgraded from per-device pre-shared passphrases to EAP-TLS - certificate-based mutual authentication. On paper, a significant improvement. In practice, the upgrade was implemented with:
- All devices sharing the same client certificate.
- No mobile device management (MDM) used to deploy the Wi-Fi profile, meaning users configured their own connections and did not enable server authentication. This omission left the door open to man-in-the-middle attacks and credential harvesting.
- A public certificate authority issuing client certificates, with the RADIUS server not configured to validate certificate content.
The
result: any certificate from that public CA could authenticate to the
Wi-Fi network. The mechanism had been upgraded; the operational
discipline had not followed it. For more on securing the RADIUS layer of
this architecture, see our guides to Wi-Fi security with RADIUS and making RADIUS more secure.
Organisations love upgrading mechanisms. They rarely upgrade and sustain operational discipline.
The most dangerous misconception: security requires friction
Many IT decision-makers assume that stronger security necessarily means more interruption: more prompts, more delays, more helpdesk calls. This assumption shapes decisions in ways that often weaken overall security posture, and I think it is worth examining directly.
When security creates too much friction, people route around it. Shadow IT is frequently a symptom of AAA bottlenecks. If a developer needs a virtual machine and the internal process takes two weeks, they will spin one up on a personal device or personal account. Workers will pay for SaaS tools out of their own pockets rather than navigate a slow procurement process. In doing so, they are handing company data to third parties, which is, technically, an internal data breach.
Cognitive overload compounds this. Security decisions made under interruption are unreliable. Users who accept MFA prompts they did not trigger, or who click through certificate warnings because they see them constantly, have been trained into autopilot by systems that ask too much, too often, for insufficient reason.
Effective AAA security architecture optimises for survivability without destroying throughput. That means:
- Device trust authentication that reduces MFA fatigue for known devices at known locations.
- Time-limited privilege elevation.
- Approved tooling that makes the secure option as convenient as the insecure workaround.
- Self-service incident reporting and password reset so that the first step in a security incident does not feel like standing outside the headteacher's office.
Security does not need to look like security to be effective. Good AAA security architecture works in the background, and users barely notice it.
AAA security best practices: where to focus when the foundations are solid
If your AAA implementation is sound but you are concerned about the surrounding architecture, here is where I would direct attention first:
Implement network segmentation. Treat internal networks as hostile. Reduce east-west movement between unrelated systems. With modern network automation, deploying VLANs is not an expensive undertaking, and every VLAN crossing presents an opportunity to apply a well thought out firewall rule or access control.
Segment shell-access systems aggressively. Any vendor system accessible via SSH, RDP, or PowerShell is essentially a jump host, whether you think of it that way or not. These systems deserve aggressive segmentation and monitoring.
Understand how attackers see your network. They are not using your web applications. They are using direct protocols, API endpoints, exposed databases, and infrastructure pathways. Audit your network from that perspective, not from the perspective of a well-intentioned user.
Build a consultative security culture. Policies handed down without consultation tend to be read, acknowledged, and ignored. Policies that emerge from a conversation with the people they affect (including junior developers, helpdesk staff, and operational teams) are more likely to be followed, and more likely to be accurate. Those people know where the real friction points are.
Know your own weaknesses. One indicator I rely on when assessing an organisation's security posture is the ability of the people running it to articulate specifically where the gaps are. Confident, specific awareness of known weaknesses generally means those weaknesses are being actively managed. Confident assertions that everything is fine because a lot was spent on a solution are a different matter entirely.
Need more help?
At InkBridge Networks, we have spent over 25 years building and securing the authentication infrastructure that enterprises, ISPs, and universities depend on. Our team includes the engineers who created and maintain FreeRADIUS, contributed to RADIUS protocol standards, and have designed AAA architectures for some of the world's most demanding network environments.
If your organisation is reviewing its AAA security posture or planning an infrastructure upgrade, we would be glad to discuss your specific situation. Request a quote to get started.
Frequently asked questions about AAA information security
What is AAA in information security?
AAA stands for Authentication, Authorisation, and Accounting. It is the framework that controls who can access a network, what they are permitted to do once connected, and what activity is recorded during their session. RADIUS is the most widely deployed protocol implementing AAA in enterprise and ISP environments.
What is the difference between Authentication and Authorisation in AAA?
Authentication verifies identity - it answers the question "is this really you?" Authorisation determines access rights - it answers, "what are you allowed to do?" Authentication happens first; authorisation follows from it. A user can be correctly authenticated but still have very limited authorisation, depending on their role and the organisation's policies.
What are the most common AAA security architecture gaps?
The three most common gaps I encounter are: senior accounts being exempted from standard controls (VIP exceptionalism), helpdesk staff carrying disproportionate privilege without appropriate monitoring, and flat networks that allow lateral movement after a credential is compromised - regardless of how strong the initial authentication was.
Is RADIUS still the right protocol for AAA security?
RADIUS remains the dominant protocol for network AAA, used by enterprises, ISPs, universities, and telecommunications providers worldwide. Its security posture has improved significantly with modern implementations, including RADIUS over TLS (RadSec). The protocol itself is not typically the weak point in most enterprise security architectures.
What should I prioritise if my AAA security is strong, but I am still concerned?
Network segmentation is usually the highest-leverage starting point. If a credential is compromised, segmentation limits what an attacker can reach from that foothold. After that: audit your privileged access pathways, review vendor and third-party access arrangements, and assess whether your shell-access systems are treated with the same rigour as your front-facing infrastructure.
Related Articles
The RADIUS protocol: How it works and why it's secure
Learn how security-by-design improvements have transformed RADIUS into a more secure protocol than the expensive platforms built on top of it.
RADIUS security best practices: How to harden your deployment
RADIUS has several well-known security limitations, most of which are easy to mitigate once you know what to do. This guide walks through five common weaknesses in the RADIUS protocol and the practical steps you can take to harden your deployment against each.