Should organisations keep RADIUS-backed appliance administration or move to local accounts?

That choice depends on operational need, but the key is to remove unnecessary trust paths. If centralised admin authentication is required, it must be tightly scoped and monitored. If it is not required, local accounts reduce one exposed dependency and simplify the attack surface on the management plane.

When Does Centralised Appliance Administration Still Make Sense?

RADIUS-backed administration is justified when a management plane needs shared policy, central revocation, consistent logging, or a single control point for privileged access. That is most defensible for fleets with many operators, formal change control, or audit requirements. The trade-off is that the admin path now depends on an always-reachable external trust service.

The core question is not whether central authentication is fashionable, but whether it adds more control than exposure. If the appliance is critical and the admin population is small, the operational benefit of RADIUS may be marginal compared with the extra failure mode it introduces.

Local accounts are often the cleaner choice when the appliance is sparse, isolated, or only managed by a small break-glass group. They reduce coupling to external identity infrastructure and can make recovery simpler during upstream outages, but they also shift responsibility for password quality, rotation, and account review onto the appliance owner.

What Changes in the Security Model When You Keep RADIUS?

RADIUS-backed admin access creates a central dependency for a high-value target: the management plane. If that dependency is abused, unavailable, or overly broad, the impact is not limited to one appliance. It can affect every system that trusts the same authentication path, which is why scope and segregation matter as much as the protocol itself.

Good use of RADIUS here means tightly scoping who can log in, what privilege they receive after login, and how quickly access can be revoked. It also means treating the authentication path as production infrastructure, because a weakly governed admin service becomes a lateral-movement enabler rather than a control.

That risk is not theoretical. In the Salt Typhoon telecom intrusions 2025, attackers used stolen credentials and later harvested TACACS/RADIUS-related material to deepen persistence across network devices. The lesson for appliance administration is straightforward: centralised login paths must be monitored as privileged attack surfaces, not treated as routine convenience layers.

How to Decide Between RADIUS-Backed Admin and Local Accounts

Choose RADIUS when you need enterprise-wide authentication consistency, strong operator attribution, and the ability to revoke access centrally without touching each device one by one. Choose local accounts when the appliance is few in number, management must survive identity-provider outages, or the trust boundary is intentionally narrow.

One practical rule is to keep at least one local break-glass account even if RADIUS remains the normal path. That preserves recovery if directory, network, or radius service dependencies fail, while still allowing centralized control for day-to-day administration. If you do this, the local path should be tightly protected, rarely used, and explicitly tested.

For a broader example of how appliance credentials can be exposed when central authentication is present, Ivanti Connect Secure exploitation 2024 shows why exposed management credentials, service accounts, and related secrets need careful scoping and visibility. The control objective is not centralisation for its own sake, but minimising the number of places where a single compromise can unlock privileged access.

Risk and Threat Considerations

RADIUS-backed administration increases the blast radius of credential compromise, mis-scoped privilege, or authentication outage because the same trust path can govern many appliances. Local accounts reduce that shared dependency, but they can also accumulate unmanaged passwords and inconsistent review if ownership is weak.

Failure mechanism: Attackers target the shared admin authentication path, steal or reuse privileged credentials, or exploit weakly governed fallback access. If the central service is down, teams may also bypass normal controls to regain access, which can create undocumented exceptions and lingering exposure.

Impact: A compromise or misconfiguration can expose the management plane, enable persistence, and slow recovery across multiple appliances. In the worst case, the organisation trades one operational convenience for a centralised privilege choke point that is easier to abuse and harder to contain.

Practitioner Guidance

What to verify: Confirm whether the appliance truly needs central authentication for day-to-day administration, or only for audit convenience. If the answer is convenience, local accounts are usually easier to defend. If the answer is operational necessity, verify that the RADIUS dependency is segmented, monitored, and recoverable.

Decision rule: Use RADIUS only where you can prove the admin path is tightly scoped, logged, and bounded by least privilege. If you cannot show who can authenticate, what they can do, and how quickly access can be revoked, the central path is too broad for privileged administration.

Practitioner takeaway: The best design is the one that removes unnecessary trust without sacrificing recovery. Keep central authentication only when it materially improves control, otherwise prefer local accounts with a protected break-glass process and disciplined rotation.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations keep appliance-based RADIUS for some environments and cloud RADIUS for others?
• Should organisations replace local accounts or keep them with tighter controls?
• Why do non-human identities create more audit risk than human accounts?