Not because it failed, but because someone noticed it was storing more than it should. GDPR does not care if your RADIUS server is critical to authentication. It only cares if you collect, store, or transmit personal data without a lawful basis. And most RADIUS implementations do.
GDPR and RADIUS are often at odds. RADIUS was built for speed and simplicity, not for 2024’s data protection landscape. Yet user attributes, identifiers, and logs from RADIUS sessions are personal data under GDPR. This means everything from usernames, IP addresses, and login timestamps to accounting details can trigger full compliance obligations.
Compliance starts with mapping your RADIUS flows. You need to know exactly what your RADIUS server collects, where it stores it, and who can access it. Run packet captures. Review accounting logs. Many setups use proxies and third-party integrations. This extends your risk surface — and under GDPR, your responsibility.
The principle of data minimization is key. If your RADIUS config logs every attribute for convenience, you are creating unnecessary exposure. Strip unneeded attributes from Access-Accept packets. Rotate logs often and avoid indefinite retention. When logs are required for operational or security purposes, encrypt them at rest and enforce strict role-based access.
Do not ignore the right to erasure. If a user makes a request, you must be able to locate and delete their personal data from your RADIUS logs quickly. That means designing systems where deletion is simple and complete, without breaking authentication flows.