Should organisations keep appliance-based RADIUS for some environments and cloud RADIUS for others?

Why mixed RADIUS models become an identity control problem

RADIUS is not just a transport choice, it is part of how access decisions are bound to a user, device, or network location. When appliance-based and cloud radius both exist, the real question is whether they enforce the same policy, attribute logic, logging, and failover behaviour. If they do not, the environment can drift into two different authentication realities.

That drift usually shows up in the mechanics: one path may accept different group mappings, different challenge flows, different certificate trust anchors, or different session attributes than the other. Over time, those differences create inconsistent identity binding across access paths, which makes troubleshooting and governance harder even when each platform looks “correct” in isolation.

When splitting control is defensible

A split model can make sense when there is a clear operational boundary that cannot be met safely with one platform. Common examples include disconnected sites, latency-sensitive locations, regulatory segregation, legacy network gear that cannot be migrated cleanly, or environments that require independent resilience planning. In those cases, the architectural split should be intentional and documented, not inherited by accident.

The standard to apply is whether each environment still maps to one governed authentication model, one source of truth for policy, and one consistent review process. If the answer is yes, the split may be an implementation detail. If the answer is no, the organisation is carrying two access control models under one name, which is usually a sign of weak standardisation rather than good architecture.

What a good mixed design must preserve

If both RADIUS patterns remain, the design should preserve policy equivalence for authentication strength, user and device attributes, session timeout, step-up behaviour, and logging. It should also preserve operational equivalence for enrollment, certificate or secret handling, change control, and incident response. The point is not identical tooling, but identical assurance outcomes.

That is where governance matters most. Appliance-based RADIUS and cloud RADIUS can both work, but only if teams can prove that access decisions are being made against the same rules and that exceptions are deliberate. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for aligning authentication, access control, auditability, and configuration management around one control objective.

Risk and Threat Considerations

Mixed RADIUS models increase exposure when policy drift, stale secrets, or inconsistent trust paths let different environments answer the same authentication request differently. That can weaken assurance, hide misconfigurations, and make it easier for an attacker to find the softer path between sites or platforms.

Failure mechanism: Divergent configuration or secret handling creates different trust decisions, weaker revocation hygiene, or different logging depth across the two RADIUS paths. If one path is easier to abuse, adversaries and insiders will gravitate to it, and defenders may miss the discrepancy because the access experience still looks normal.

Impact: The organisation can end up with inconsistent identity binding, harder incident investigation, and a larger blast radius if one authentication plane is compromised. In network environments, credential reuse and radius key exposure can also enable persistence and lateral movement; Salt Typhoon telecom intrusions 2025 is a reminder that access-plane compromise can become long-lived infrastructure compromise when authentication secrets are reused or poorly governed.

Practitioner Guidance

What to verify: Confirm that both RADIUS paths enforce the same identity source, the same attribute-to-policy mapping, and the same revocation and logging standards. If you cannot demonstrate equivalence on those points, treat the split as a control gap rather than an acceptable hybrid.

Decision rule: Keep both only when there is a documented operational boundary that requires it and when each boundary can still be governed as one authentication model. Otherwise, converge to a single design and use location-specific exceptions only where the business case is explicit.

Practitioner takeaway: Mixed RADIUS is justified by operational necessity, not convenience; if it creates two different answers to the same access question, the architecture is already failing the governance test.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How can organisations reduce the blast radius of compromised agent identities?
• How do organisations keep API policy consistent across cloud environments?