Posts

Showing posts from September, 2026

AAA Modernization: How to Build a CISO-Ready Security Business Case

  This cost of standing still has been priced. In principle, the budget committee has agreed. The legacy AAA platform replacement is on the roadmap. It then reaches the security architecture review, which raises questions unrelated to cost. What's today's exposure? Which controls are changed? What risk remains afterwards, and who is responsible? This is a different document. Not the finance case with the word "risk" pasted on top. A CISO evaluates residual risk ; cases not written with this in mind often stall. The new guide explains how to build one. It is organised around three key areas a security team evaluates: attack surface, compliance and audit exposure, and detection and containment speed. For each area, compare the legacy platform's impact, the modern platform's effect, and the specific control that drives change. There's a worked scoring row in there, using a credential-stuffing run against the broadband realm, so you can see what a scored sc...

AAA Server Reliability: Key Metrics Telecom Operators Should Track

  Most of the reliability conversation around AAA runs one way: how do you verify a vendor's availability claims before you buy? Our latest blog turns that around. Once your AAA platform is reliable, how do you prove it to a regulator who can fine you and to an enterprise customer deciding whether to renew? Sandeep Kalekar breaks the problem down by audience. Regulators rarely name AAA directly, but most jurisdictions require operators to report outages and security incidents above defined impact thresholds, and an AAA failure that stops subscribers from authenticating will usually cross them. What regulators want is compliance-format reporting: incident notifications within set windows, post-incident reports covering root cause, subscriber impact, and remediation, and evidence that redundancy and failover were in place and tested before the failure. The post points to the FCC outage-reporting regime and the EU's NIS2 directive as comparable frameworks. Enterprise, wholes...

TACACS+ Server Evaluation: 12 Criteria to Compare Before You Choose

  Choosing a TACACS+ server rarely comes down to a feature-count contest. In this Alepo blog, Vishal Mathur argues that three criteria decide most evaluations: how granular command authorization is, whether the server works across every device platform in your estate, and whether there is a supported migration path from whatever you run today. Before comparing vendors, the article asks operators to settle three questions: how many devices need authentication and how many sit outside the primary region; how many distinct administrative roles the organisation really has (usually four to eight); and what legacy system is being replaced and what it contains.  The checklist itself covers twelve criteria, each with a weight and a way to verify it: standards conformance and a dated RFC 9887 (TACACS+ over TLS 1.3) roadmap; command authorization granularity; identity store and MFA integration; multi-realm and tenant isolation; device interoperability; accounting depth, retention and qu...