The four roles
Every user has exactly one role. It decides what they may do; the site scope in the next section decides which devices they may do it to. The two are independent, and both apply.
| Role | What it can do |
|---|---|
| superadmin | Passes every permission check and always sees the whole fleet — a site scope cannot be applied to it. User accounts, site access and API keys belong to this role alone, as does resetting another user's password, two-factor authentication or passkeys. The account created on first install has this role. |
| admin | Manages devices, sites, backups, upgrades, webhooks and settings — everything except user accounts and API keys. Can be scoped to specific sites, and additionally sees devices that belong to no site. |
| operator | Day-to-day work on devices: commands, upgrades, backups, configuration changes. No user management and no system configuration — only its own password, second factor and passkeys. |
| viewer | Read-only. Sees device status, interfaces, logs and recorded metrics, and changes nothing beyond its own password, second factor and passkeys. |
Pick the lowest role that lets someone do their job. An operator who needs to read one setting is still an operator; the fix is not to promote them.
Per-site access
A user is either unrestricted — the whole fleet — or scoped to an explicit list of sites. There is no in-between, and the distinction matters more than it looks:
- A user who has never been scoped sees every site. This is deliberate, so that upgrading an older installation does not silently take access away from anyone.
- A user who is scoped sees exactly the sites on their list. A scoped user with an empty list sees nothing at all — that is a valid state, not a bug.
- superadmin ignores this entirely and is always unrestricted.
Devices that belong to no site are a separate case. A scoped operator or viewer never sees them, whatever is on their list; only superadmin and admin do. An unrestricted user of any role still sees the whole fleet, those devices included — but it remains a good reason to put every device in a site.
The scope reaches past the device lists. It also governs webhooks, the auto-block tables on the Security page and the activity log: a scoped admin manages only webhooks whose own site list sits inside theirs, reads the reporting device's name in the auto-block tables only for their own devices, and sees an audit trail covering their sites plus whatever belongs to no site, such as sign-ins. (v1.94.0+)
Who manages the sites themselves
Creating, renaming and deleting a site is done by a superadmin, or by an administrator with no site limits (v1.94.0+). An administrator limited to certain sites does not get those buttons. The reason is the line below: granting access to a site is a superadmin action, so a scoped administrator creating a site would produce one they could not then see, and could not grant themselves. If your organisation onboards customers regularly, the person who does it should hold a superadmin account — it is a role, and you can have several.
Granting access
Scope is set on the user, and only a superadmin can set it. Open Users, edit the person, tick Limit to specific sites and choose them. The same list can then be edited from the other end: open Sites, edit a site, and use User access to tick which of the scoped users may see its devices. Unrestricted users are not offered there, because they already see every site.
A change to someone's role or sites, or switching their account off or deleting it, applies at once: from their next request, and within half a minute on a page they have left open. (v1.97.3+)
Changing your password
Every user changes their own password under Settings → Password, whatever their role. It asks for the current password as well as the new one, so a browser someone left signed in is not enough to take the account over. (v1.89.0+)
Other browsers signed in to the same account are signed out the next time they reach the server, and a page left open stops receiving live updates within half a minute; the one you made the change from stays signed in. (v1.97.3+) For someone who has forgotten their password, a superadmin sets a new one from Users. No other role can set another user's password.
The admin account a new installation starts with has the password admin. While it does, signing in to it opens a screen that asks for a new password, and the account can do nothing else until it has one. API keys are not affected. (v1.97.0+)
Two-factor authentication
TOTP adds a six-digit code from an authenticator app — Google Authenticator, Authy, 1Password, Microsoft Authenticator or any other — to the sign-in.
Each user turns it on for themselves under Settings → Two-factor auth. The setup shows a QR code and the secret in text, for apps that cannot scan. Switching it on, or off again, signs every browser out shortly afterwards, including the one you did it from; sign in again and the new second factor applies.
When you enable it you are shown eight backup codes, once. Each is single-use and they are stored hashed, so nobody — including a superadmin — can read them back to you later. Save them somewhere that is not the laptop you sign in from. You can regenerate the set at any time from the same screen, which invalidates the previous one.
Passkeys and security keys
A passkey — WebAuthn or FIDO2: an Apple or Google passkey, a YubiKey, Windows Hello — can be used as the second factor instead of typing a TOTP code. Register one under Settings → Passkeys. It replaces the code, not the password: signing in still starts with a username and password.
There is a hard requirement worth knowing before you try: passkeys need a registrable domain over HTTPS. The WebAuthn specification forbids an IP address as the relying-party identity, so an installation reached as https://10.0.0.5 cannot offer them no matter how the certificate is set up. The interface says so rather than failing obscurely. A reverse proxy with a real hostname and a certificate — Let's Encrypt, or a dynamic-DNS name — is what makes the option appear.
Registering or removing a passkey signs you out, by design: the next sign-in proves the change took effect.
When someone is locked out
A user who has lost both their authenticator and their backup codes cannot recover on their own. A superadmin resets them from Users:
- Reset 2FA — the user signs in with just their password until they enable it again.
- Reset passkeys — removes every registered passkey. The user signs in with their password, plus TOTP if they still have it, until they register a new one.
Both actions are recorded in the activity log. There is no email reset and no other way back in. If the locked-out account is the only superadmin, there is no in-app path back — which is the argument for having a second superadmin account, and for keeping its backup codes somewhere separate.
API keys
Machine access does not use a user's password. A superadmin issues a key on the API Keys page; a key carries its own role and its own site scope, resolved by the same rules as a user's. A monitoring integration should get a viewer key and nothing more — that is exactly what the Zabbix template asks for.
A key's role stops at admin. There is no superadmin key, and no key can manage user accounts or other keys, whatever role it holds. You can give a key an expiry date or leave it open-ended, and revoke it at any time. The token itself is shown once, when the key is created, and cannot be read back afterwards — if it goes missing, revoke that key and issue another.
AI assistants (MCP)
The manager can answer questions from an AI assistant directly, without anything installed alongside it. Turn on Settings → MCP endpoint and point the assistant at /mcp with one of your API keys. Until you turn it on, that path does not exist as far as any caller is concerned — it answers 404 whether or not they present a valid key.
What an assistant can ask for is a fixed list of ten questions, not the whole API. Each one is shaped around something a person actually asks, and each answers in plain text or a small table rather than raw JSON.
| Tool | Answers |
|---|---|
mikr_issues | Everything flagged right now, in one reply: devices not reporting, RouterOS and firmware behind their channel, PoE budgets over 80%, devices where the manager only has a read-only RouterOS account, BGP sessions down or flapping, gaps in the metrics history, CVEs matching installed versions, backup problems. The one to start a morning with. |
mikr_fleet | The overview: how many devices, the breakdown per site, the spread of RouterOS versions and models, and who is not reporting. |
mikr_device | One device in detail — model, versions, uptime, CPU, memory, temperature, PoE draw against its budget. It can also pull ports, discovered neighbours, routes, DHCP leases or wireless clients live from the device; each of those costs a round trip to the hardware, so they are asked for explicitly. |
mikr_search | Find a device by name, IP, RouterOS identity, model, board, version, tag or note. Answered from the manager's own database, so it is instant and touches nothing. |
mikr_upgrades | Who is behind, what they run, what is available, and the latest release per channel. It reports stored poll results: it does not make devices re-check, and it cannot start an upgrade. |
mikr_backups | Backup coverage: healthy, never backed up, overdue against their schedule, unscheduled, or whose most recent backup was truncated. |
mikr_cve | Known RouterOS CVEs matched against the versions actually installed, with the affected devices named. Filterable by severity. |
mikr_metrics | Recorded history of one metric on one device — CPU, memory, temperature and the rest of the health sensors — over 1h to 30d. Without a metric named, it lists which ones have samples. |
mikr_syslog | Search the syslog the manager has collected, newest first, filtered by device, text, topic or maximum severity. |
mikr_topology | Discovered neighbour links with the ports they land on. Links are held per site, so ask for a site; the fleet-wide call lists nodes only. |
Devices are addressed the way you would say them out loud — by name, by RouterOS identity, or by IP. There is no internal id to look up first.
It reads and never writes. There is no tool for upgrading, rebooting, running a command or changing a setting. An assistant that decides a device should be rebooted can tell you so; it cannot do it.
The key decides the rest. Everything the tools read passes through the same checks a browser session goes through, so an assistant using a viewer key scoped to one site sees that site, as a viewer — the same page a person with that key would get. Issue the key you would be comfortable handing to whoever operates the assistant, and revoke it in the same place.
https://your-manager:3000/mcp and a header X-API-Key: mikr_…. The transport is HTTP; there is no separate port and nothing to install on the server.Assistants that run in a browser
A client running in a browser — claude.ai and anything built the same way — has no config file to read a key from. Rather than ask you to paste one into a web page it does not control, it looks for a sign-in, and refuses to connect if there is none. Since v1.74.0 the manager provides one.
Fill in Settings → MCP endpoint → Public URL with the external HTTPS address your install answers on, then add the connector in the assistant using https://your-address/mcp. The browser opens a consent screen served by the manager, which asks for one API key and nothing else — no username, no password. Approving it connects the client with exactly that key's role and site scope.
What you connect stays visible and stays yours to cut: connected clients are listed on the API Keys page with the key each one used, when it connected and when it last read anything. Disconnect one there, or revoke the key to disconnect everything using it — either takes effect on the assistant's next question. Changing a key's role or its sites applies just as immediately, with nothing to reconnect.