If you followed our VPN 2FA with RADIUS guide, you already have everything needed to protect something else: logins to the router itself. WinBox, WebFig, SSH and the API can all authenticate over RADIUS, and since the Notakey auth-proxy is transparent RADIUS, pointing the router’s login service at it means every admin login needs a phone approval, not just a password.
The flow is identical to the VPN case:
Router login ──RADIUS──▶ Notakey auth-proxy ──RADIUS──▶ your RADIUS server
│
└──▶ push notification ──▶ admin's phoneOnly three things change on the router side, covered below.
Requirements
- A working auth-proxy in front of a RADIUS server, set up exactly as in steps 1–3 of the VPN guide. Any downstream RADIUS works: FreeRADIUS, Microsoft NPS, MikroTik’s own User Manager, or the Notakey RADIUS plugin.
- The admin’s username present in the downstream RADIUS server and in the Notakey service, with an onboarded phone; the proxy addresses the push by username.
Step 1: Decide which push message admins see
The proxy pushes the message from its own configuration: the same
message_title / message_description used for VPN logins. You have two
options:
- Reuse the VPN proxy as-is. Fastest. Admin logins will show the VPN wording on the phone (e.g. “VPN authentication — allow john login?”). Perfectly workable for a small setup.
- Run a second proxy instance with its own Notakey application and a
message like “Router admin login as {0}?”. With the dockerized proxy this
is just a second container listening on another port (say
18120), with a differentNOTAKEY_ACCESS_ID; the appliance’s built-in proxy is a single instance, so the second one runs as a container next to it.
A dedicated message is worth the five minutes: an admin who sees “Router admin login” while not logging into a router knows immediately that something is wrong — and denies it.
Step 2: Add the proxy as a login RADIUS server
On the router, add the proxy as a RADIUS server for the login service:
/radius
add service=login address=<proxy-address> secret=secret_to_radius_server timeout=30sThis is the VPN guide’s /radius line with service=ppp swapped for
service=login, and the same warning applies: MikroTik’s default RADIUS
timeout is 300 milliseconds. A human approving a push needs at least 30
seconds, so timeout=30s is not optional. Without it every login fails
before the phone even buzzes.
Step 3: Enable RADIUS for router users
/user aaa
set use-radius=yes default-group=fullThat’s it. RouterOS now queries RADIUS (through the proxy) for any login
whose username is not in the local /user database.
Two things to get right here:
Pick default-group deliberately. RADIUS-authenticated users get this
group’s privileges (read, write or full) unless your RADIUS server
returns a Mikrotik-Group vendor attribute per user (vendor ID 14988). If
everyone coming through RADIUS is a full admin, default-group=full is fine;
if not, set it to the least privilege that works and assign Mikrotik-Group
from RADIUS for the exceptions.
Keep a local admin account. RouterOS checks the local user database
first and only asks RADIUS for usernames it doesn’t know. That local admin is
your fallback if the proxy, the RADIUS server or the Notakey service is ever
unreachable. Without it, an outage locks you out of your own router. Give it
a strong unique password, and consider restricting it to a management address
with /user set <name> address=<mgmt-subnet>.
Test it, carefully
Do not close your working session yet. Open a second WinBox or SSH session and log in with a RADIUS username:
- The login dialog waits; that’s the proxy holding the exchange open.
- The push lands on the phone. Approve → you’re in, with the group’s privileges. Deny or ignore → the login fails after the timeout.
- Confirm the local admin still gets in the normal way.
Only after both checks pass, close the original session.
If logins fail instantly even though the push arrives, recheck
timeout=30s in /radius; the 300 ms default is the most common mistake.
If no push arrives at all, the username almost certainly differs between
RADIUS and the Notakey service.
Where this fits
One proxy, one RADIUS server, and now both the VPN and the router’s admin plane require a phone approval. The same pattern extends to anything else that speaks RADIUS.
Related guides
- VPN 2FA with RADIUS — the complete auth-proxy setup, the proxy configuration this guide builds on
- Linux SSH 2FA with pam_radius: the same proxy protecting SSH, sudo and su
- MikroTik VPN 2FA — the complete script-based setup, a RADIUS-free alternative for the VPN itself