An AAA (Authentication, Authorization, and Accounting) server implementation succeeds or fails on the work done before the software is installed. This AAA server implementation checklist walks telecom operators through six phases – planning, infrastructure, configuration, integration testing, parallel running, and post-cutover validation – with the specific checks that catch the problems teams usually discover in production. Budget more time for testing and parallel running than for configuration. That ratio is the single most reliable predictor of a clean cutover.
Why an Implementation Checklist Matters
Authentication is the one system in an operator’s network that every subscriber touches on every session. When a billing report is wrong, finance notices at month-end. When AAA is wrong, subscribers notice within seconds, at whatever hour the problem starts.
That asymmetry is why an AAA deployment checklist earns its keep. Most of the failures we see in AAA rollouts are not software defects. They are things nobody checked: a firewall that passes authentication traffic on UDP 1812 but silently drops Change-of-Authorization (CoA) on UDP 3799, an accounting interim interval set so low it floods the mediation system on day one, a network access server (NAS) with a mistyped shared secret that fails without producing a single error message on either side.
Every one of those is cheap to catch in a checklist review and expensive to catch in production. The six phases below are ordered the way the work actually happens. Skipping ahead is how projects get into trouble – configuration before the integration list is final means configuring twice.
The checklist covers the full implementation lifecycle, from first traffic measurement to post-cutover validation. If your question is narrower – specifically how to move live subscribers across without dropping sessions – the zero-downtime AAA migration checklist goes deeper on that phase alone.
Phase 1: Pre-Implementation Planning
Planning is where the project’s real difficulty gets measured. The goal of this phase is a complete inventory – of traffic, equipment, integrations, and data – because every unknown here becomes a surprise in Phase 4.
Traffic and scale:
- Measure peak authentication rate in requests per second, from live data rather than an estimate. Then size for the re-authentication surge after a regional power event, when every ONT and CPE in an area reconnects at once. That surge, not the daily peak, is your real capacity requirement.
- Measure accounting volume: starts, stops, and interims per second, and total records per day. Accounting usually outweighs authentication by a wide margin.
- Count concurrent sessions the platform must hold in state.
Network estate:
- Inventory every NAS that will talk to the new server – BNG/BRAS platforms, wireless LAN controllers, packet-core elements – with vendor, model, and software version. Vendor-specific attributes differ between Cisco, Nokia, and Juniper BNGs, and between Cisco, Aruba, Ruckus, Huawei, and MikroTik on the Wi-Fi side.
- Export the attribute dictionaries and vendor-specific attributes (VSAs) your current AAA uses. Undocumented VSAs are the most common migration surprise in brownfield projects.
- List every authentication method in live use: PAP, CHAP, MS-CHAPv2, and each EAP method (EAP-TLS, EAP-TTLS, EAP-PEAP, and EAP-SIM/AKA/AKA’ if you carry Wi-Fi offload or Wi-Fi calling traffic).
Integrations and data:
- List every system the AAA touches: HSS/UDM over Diameter (SWx, S6b), the Policy and Charging Rules Function (PCRF) over Gx, the Online Charging System (OCS) over Gy, and Business Support Systems (BSS) and CRM provisioning over APIs. Each is its own test workstream later.
- Scope the data migration: subscriber profiles, realms and domains, policy definitions, and where each lives today.
- Define success criteria in numbers – authentication success rate, response latency, accounting completeness – and get them agreed before anyone installs anything.
- Write the rollback criteria now, while nobody is under cutover pressure. Deciding mid-incident what counts as “roll back” is how teams talk themselves into pressing on.
Assign a named owner to each integration. In our experience the projects that slip are rarely short of engineers; they are short of one person who is unambiguously responsible for, say, the Gy interface working.
Phase 2: Infrastructure Setup
With the inventory complete, the infrastructure decisions become mostly mechanical. Two of them deserve real thought.
The first is deployment model. A modern carrier AAA runs as containers on Kubernetes, on virtual machines, on bare metal, in private cloud, on premises, or as a managed service the vendor operates for you. The right answer depends on your latency budget, data-residency obligations, and how much operational ownership your team wants – the Alepo AAA Server page sets out the models side by side. The second is redundancy topology. For subscriber authentication, active-active geo-redundancy is the standard to hold yourself to; an idle standby that has never taken live load is a hope, not a design.
Then the checklist items:
- Size compute and storage against the Phase 1 surge figure, with headroom for growth over the contract term.
- Open and verify firewall paths for every protocol in scope: RADIUS on UDP 1812/1813, CoA and Disconnect-Message on UDP 3799 (RFC 5176), Diameter on TCP/SCTP 3868, TACACS+ on TCP 49 if device administration is in scope. Verify means send a test packet – a firewall rule that exists on paper has caught out better teams than yours.
- Confirm CoA reachability specifically. CoA travels from the server toward the NAS, the reverse of authentication, so NAT and stateful firewalls that pass everything else can still block it.
- Configure NTP on every node. Accounting reconciliation depends on timestamps agreeing; clock drift produces disputes that look exactly like lost records.
- Stand up the PKI: server certificates for EAP-TLS/TTLS/PEAP, and the certificate lifecycle for RadSec (RFC 6614) if any transport leg crosses untrusted networks.
- Deploy monitoring before configuration starts, so you have baseline graphs from the first test transaction onward. Retrofitting dashboards after go-live is a task that never quite happens.
Phase 3: AAA Server Configuration
Configuration is the phase teams expect to be the hard part. It usually is not – but it is the phase where small errors hide longest, so discipline here pays off later.
- Define every NAS as a client with a unique shared secret. Reused secrets are common and regrettable: they turn one compromised device into a compromised estate. Note that a wrong secret does not produce an error – the server silently discards the request – so record each secret’s provenance as you go.
- Build the realm and domain structure, and decide explicitly how unknown realms are handled.
- Configure each authentication method from the Phase 1 list, and bind the certificates for the EAP methods that need them.
- Set the accounting interim interval deliberately. Shorter intervals give finer usage data and multiply record volume in equal measure; whatever you choose, confirm mediation and billing can absorb it.
- Load vendor dictionaries and VSAs for every NAS vendor in the estate.
- Configure authorization policy: service profiles, bandwidth tiers, quota rules, and the CoA profiles that change live sessions when a subscriber tops up or a policy changes.
- If TACACS+ device administration is in scope, define command authorization sets and audit logging per admin role.
- Set up role-based access for your own administrators, and set log retention to match your regulatory obligations rather than the product default.
Keep every configuration change in version control from the first day. When parallel running turns up a discrepancy, “what changed since Tuesday” needs a better answer than memory. This habit matters more on the platforms that make change easy.
Phase 4: Integration Testing
Testing is where the Phase 1 inventory proves its worth: every line item becomes a test case. The temptation is to test the happy path per interface and declare victory. Resist it – the incidents that hurt come from the combinations.
- Authenticate through every NAS vendor and model in the estate, with every authentication method that vendor carries in production. Build the full matrix and work through it – sampling misses exactly the combinations that break.
- Test each Diameter peer individually – SWx and S6b against the HSS/UDM, Gx against the PCRF, Gy against the OCS – then run combined call flows that exercise them together.
- Send a CoA and a Disconnect-Message to every NAS group and confirm the session actually changes. This is the test most often skipped, and the failure most often found after cutover.
- Reconcile a full day of accounting records against mediation, record by record. Sampled checks miss systematic gaps.
- Run failure drills: kill a node mid-load, then fail an entire site. Sessions should survive; if they don’t, you have a redundancy design problem, and better to learn it now.
- Load-test to the Phase 1 surge figure – not the average, the surge.
- Test the failure paths deliberately: wrong shared secret, expired certificate, unreachable HSS, malformed request. How the platform degrades matters as much as how it performs.
- Exercise the provisioning APIs from your live BSS with production-shaped data, including its worst legacy records.
For FTTH and broadband operators there is a revenue dimension to the accounting tests in particular – unbilled sessions are money – which we cover in how AAA supports FTTH security, authentication, and session efficiency.
Phase 5: Parallel Running and Cutover
However thorough the testing, live traffic finds things test plans miss. Parallel running exists to let it find them while the legacy platform is still answering.
The approach that works is staged. First, shadow mode: mirror live authentication traffic to the new platform and log its responses without acting on them, then compare its answers against the legacy system’s over at least a week of real traffic, including a weekend. Discrepancies here are gold – each one is an incident that never happened.
- Run shadow mode until the response-match rate holds steady at your agreed threshold across a full weekly cycle.
- Investigate every mismatch to root cause. “Probably fine” is not a disposition.
- Cut over one NAS group or realm at a time, lowest-risk first, with a soak period between waves.
- Keep the legacy platform running and ready to take traffic back throughout. Rehearse the rollback once, for real, before the first wave – a rollback that has never been executed is a document, not a capability.
- Migrate accounting last, after authentication is stable, and reconcile against legacy for every wave.
- Schedule waves inside agreed maintenance windows, with NOC and support teams briefed on what to watch and who to call.
- Hold a defined hypercare period after the final wave – daily checkpoint, accelerated escalation, vendor on standby.
Moving traffic one realm at a time with rollback armed is standard practice in AAA migrations, and it is the reason well-run cutovers are boring. Boring is the goal.
Phase 6: Post-Implementation Validation
The project is not done at cutover. It is done when the numbers say so.
- Compare authentication success rate, response latency, and accounting completeness against the Phase 1 success criteria – over several weeks, so the comparison includes at least one traffic peak.
- Reconcile one complete billing cycle end to end before anyone touches the legacy platform. This is the last check that can catch a systematic accounting gap while recovery is still simple.
- Decommission legacy only after that reconciliation closes clean. Archive its configuration and historical logs first; auditors ask.
- Turn the implementation into operations: runbooks for the ten most likely incidents, alert thresholds tuned against the new baseline, and monitoring dashboards the NOC actually uses.
- Train the operations team on the new platform before hypercare ends, while the implementation engineers are still on hand.
- Run a security review: default credentials gone, admin access role-based and logged, certificate expiry dates in the renewal calendar rather than in someone’s memory.
- Hold a lessons-learned session and write it down. Your next network – 5G core, Wi-Fi expansion, an acquisition – will reuse this checklist.
Frequently Asked Questions
Q1. How long does an AAA server implementation take?
Long enough that the schedule should be built from the integration list rather than from a calendar target. For an operator replacing an existing platform, planning and infrastructure usually run a few weeks each, integration testing runs longer, and parallel running plus staged cutover needs a full billing cycle behind it before legacy can be retired. Greenfield deployments run shorter because the migration and parallel-running phases fall away. The variable that moves the timeline most is the number of integrations, not the size of the subscriber base.
Q2. What is the most common mistake in AAA rollouts?
Under-testing the paths that only matter occasionally: CoA reachability, site failover, and accounting reconciliation. Authentication gets tested because it fails loudly. Accounting fails quietly, and the gap surfaces as a billing dispute weeks later.
Q3. Can we run old and new AAA servers at the same time?
Yes, and you should. Shadow mode – mirroring live traffic to the new platform without acting on its responses – followed by staged per-realm cutover is the standard approach. It is the only way to test against real production traffic with zero subscriber risk.
Q4. When should the legacy AAA be decommissioned?
After one full billing cycle has been reconciled clean on the new platform, and not before. The legacy system’s configuration and logs should be archived either way.
Conclusion
Every item in this AAA server rollout checklist comes from deployments that had to work the first time. Alepo builds carrier-grade AAA for Tier-1 and Tier-2 operators across the Middle East, Europe, LATAM, Africa, and Asia, and most of that work is replacing an AAA platform that is already carrying live subscribers rather than building on empty ground – the harder version of the job, and the version this checklist is written for.
Ready to streamline your AAA server implementation? Get the checklist and ensure a smooth, secure deployment. Book a demo to see how we can help.
