MikroTik User Management: Groups, Policies, and Role-Based Access Control

1. How RouterOS authorisation actually works

Authentication and authorisation are separate concerns in RouterOS. A user is authenticated against either the local user database or a RADIUS server; authorisation is then resolved through group membership. Each user belongs to exactly one group, and that group’s policy set is the user’s complete authorisation. The chain is strictly one-to-many-to-many:

User  ──belongs to──▶  Group  ──contains──▶  Policy flags
 │                       │                      │
 │                       │                      ├─ login/transport (ssh, winbox, api…)
 │                       │                      └─ operational (read, write, policy…)
 │
 └─ per-user attributes: address, inactivity-policy, SSH key, password

Two properties of this model matter more than any other:

• A user has exactly one group. There is no additive multi-group membership. If a person needs a blended role, you create a blended group.
• Policies are capabilities, not hierarchical levels. write does not imply read; policy does not imply write. The documentation is explicit that write “does not allow to read the configuration, so make sure to enable read policy as well”.

2. The policy reference

Policies split into two functional classes: login/transport policies that determine how a user may connect, and configuration policies that determine what they may do once connected. Several flags cross both boundaries (notably ftp and api).

Legacy note: older documentation also lists dude and tikapp. Current v7 references have dropped or deprioritised them. Treat the policy list as version-dependent and check /user group print detail on the actual device.

Hidden dependencies that break naive role design

• write without read is a trap: the user can issue changes but cannot inspect the resulting state. In practice, grant them together.
• policy without write does not produce a usable user-admin role.
• ftp is a transport and a file capability. Granting it “for backups” also grants file deletion.
• read in a custom group does not automatically include sensitive; that separation is the whole point of building custom groups.

3. Why the built-in groups are a poor RBAC baseline

RouterOS ships three undeletable groups. Their actual policy sets are the source of most MikroTik privilege-escalation findings in the wild:

The vendor’s own documentation warns that “even the read group includes sensitive, reboot, and other important policies, meaning that this group should not be given to untrusted users. For truly limited groups, make a custom group, defining specific policies”.

In other words: there is no built-in read-only group. If you hand a monitoring account the read group, you have handed it the ability to reboot the device and capture traffic.

4. Policy negation: add versus set

This is the most misunderstood mechanic in RouterOS user management, and it causes real outages when teams try to “tighten” a group and accidentally widen it.

• add is authoritative: it revokes every policy not listed. A new group created without a policy argument gets every policy negated (no rights).
• set is incremental: it changes only the policies you list and leaves the rest untouched. For example, set policy=read,rest-api on a group that already has api keeps api.
• Prefixing a policy with ! revokes it explicitly.

# DANGEROUS: this does NOT remove "sniff"; it only adds "read" and leaves the rest intact
/user group set [find name=role-noc-l1] policy=read

# CORRECT: explicitly revoke the policy you want gone
/user group set [find name=role-noc-l1] policy=!sniff

# Also correct: declare the full desired set with add-like semantics
/user group set [find name=role-noc-l1] policy=read,test,winbox,ssh,!reboot,!sensitive,!sniff

A useful habit is to self-document custom groups with explicit negations even though add already implies them. It makes audits readable and prevents a later set from silently re-adding a capability.

5. Designing a least-privilege role model

A workable MikroTik RBAC design starts from job functions, not from the built-in groups. The following matrix covers the roles most production networks actually need.

Creating the groups

/user group add name=role-noc-l1 policy=read,test,winbox,ssh,web \
  comment="NOC L1 - monitoring and triage, no reboot, no sniff, no secrets"

/user group add name=role-noc-l2 policy=read,write,test,reboot,winbox,ssh,web \
  comment="NOC L2 - approved change execution, cannot manage users"

/user group add name=role-neteng policy=read,write,test,reboot,sniff,sensitive,winbox,ssh,web,romon \
  comment="Senior network engineer - full config + packet capture, no user admin"

/user group add name=role-automation policy=api,read,write,test \
  comment="Automation account - API only, no interactive login"

/user group add name=role-auditor policy=read,winbox,web,ssh \
  comment="Read-only audit - no sensitive, no reboot, no sniff"

Creating the users

/user add name=jdoe group=role-noc-l2 address=10.20.0.0/24 \
  comment="Jane Doe - NOC shift lead"

/user add name=svc-ansible group=role-automation address=10.30.5.10/32 \
  comment="Ansible control node"

The address property (labelled “Allowed Address” in WinBox) restricts where the account may log in from and is one of the highest-value controls available per user. When set, the user may log in only from matching source addresses; logins from other addresses are refused. Bind service accounts to a single host address, and bind human accounts to management VLANs.

Role-design caveats

• Auditors and sensitive. A true auditor usually should not see secrets — so deny sensitive. If they must verify that secrets exist, use a config export reviewed under a break-glass account rather than granting standing access.
• API versus REST. In v7 these are separate flags. Grant only the one your tooling uses. Some third-party integrations and older documentation assume api is sufficient for REST; test against your RouterOS release before standardising.
• No-login automation. An automation account with only api/rest-api, read, write, and test cannot open an interactive shell. That materially reduces blast radius if the credential leaks.
• File operations. MikroTik documentation notes that all groups have access to file operations, so the policy model does not give you a clean “no filesystem” role. Treat router storage (backups, certificates, licences) as sensitive and restrict ftp and sensitive deliberately.

6. Hardening the accounts themselves

Group policy is only half of user management. The other half is reducing the attack surface of the accounts and the services they authenticate against.

6.1 Eliminate the default admin identity

/user add name=netops-breakglass password="<long-unique-passphrase>" group=full \
  comment="Break-glass only - sealed credential"

# Verify the new account works before removing the default
/user remove admin

MikroTik’s hardening guidance recommends changing the default admin username and removing the default account. RouterOS enforces one safety rule: at least one user with full access rights must exist, and if that user is the only one, it cannot be removed. Plan the break-glass account before you delete anything.

6.2 Enforce password quality

/user settings set minimum-password-length=12 minimum-categories=3

minimum-categories counts how many of the four character classes (uppercase, lowercase, digit, symbol) must be present, with a maximum of 4. Note that this setting governs local users only; RADIUS-authenticated users inherit the policy of the RADIUS server.

6.3 Prefer SSH keys over passwords

/user ssh-keys import public-key-file=netops.pub user=netops-breakglass

Assigning an SSH key to a user disables SSH password authentication for that user by default — a strong control, but also a lockout risk if the key is lost. The manual states that when at least one key is assigned, password login is refused for that user (with the default password-authentication=yes-if-no-key). Keep the break-glass account’s recovery path documented and tested.

6.4 Enforce session hygiene

/user set [find name=jdoe] inactivity-policy=lockscreen inactivity-timeout=10m

RouterOS supports lockscreen and logout inactivity actions for CLI sessions, with a minimum timeout of one minute and a maximum of 24 hours. lockscreen locks the session and requires the password to resume; logout closes the idle session with a message. Lockscreen is preferable for interactive admin sessions; logout is appropriate for automation and shared consoles.

6.5 Reduce the login surface

# Disable cleartext and unused management services
/ip service disable telnet,ftp,www,api,api-ssl
/ip service set ssh port=2200
/ip service set winbox address=10.20.0.0/24

# Disable MAC-level management on production routers
/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=none
/tool mac-server ping set enabled=no

MikroTik’s hardening guide is direct on this: production routers should be administered over SSH, secured WinBox, or HTTPS, and Telnet, FTP, plain HTTP, and unencrypted API should be disabled. MAC-Telnet, MAC-WinBox, and MAC-Ping bypass IP-layer firewall policy entirely and should be off on production networks.

6.6 Revoke sessions after policy changes

Changing a group’s policy does not necessarily retroactively reduce the privileges of sessions that are already established. After any RBAC change, inspect and terminate active sessions:

/user active print
/user active remove 0

/user active print shows the username, group, transport (ssh, winbox, api, rest-api, web, ftp), source address, and whether the session was RADIUS-authenticated. Current documentation says to terminate a session with /user/active/remove; some older releases exposed request-logout instead. Treat this as mandatory post-change hygiene.

7. Centralised RBAC with RADIUS

For fleets, local user databases do not scale. RouterOS supports RADIUS for both authentication and accounting, but the authorisation semantics need care.

• Local users take precedence. The local user database is consulted first — RADIUS is used only for usernames not found locally. Your break-glass account therefore keeps working during a RADIUS outage — which is exactly why it must exist.
• The default group matters. default-group defaults to read and applies when RADIUS sends no group or sends an excluded group. Given what the built-in read group contains, set this to a custom minimal group, not the system default.
• Restrict what RADIUS can grant. exclude-groups lists groups that RADIUS-authenticated users may not be placed into; if the server returns an excluded group, the default group is used instead. This protects against a rogue RADIUS server granting full rights. Exclude full and any group carrying policy so a compromised RADIUS server cannot mint router administrators.
• Group assignment uses a vendor-specific attribute. MikroTik’s VSA Mikrotik-Group (vendor ID 14988) carries the group name returned to the router.
• WinBox requires CHAP support on the RADIUS server.

/radius add service=login address=10.40.0.10 secret="<strong-secret>"
/user aaa set use-radius=yes default-group=role-auditor \
  exclude-groups=full,role-neteng,role-automation

The privilege-escalation logic behind exclude-groups is worth stating explicitly: a user without the policy permission could otherwise repoint the router at a RADIUS server they control and authenticate as an administrator. Excluding privileged groups, and excluding the policy capability from RADIUS-delivered roles, closes that path.

8. Verification and audit routine

RBAC drifts. A quarterly review should answer four questions: who exists, what group they are in, what that group can actually do, and where they can log in from.

# Inventory users with their group and source restriction
/user print detail

# Inspect every custom group's effective policy set
/user group print detail where name~"role-"

# Confirm nobody is sitting in a built-in group by accident
/user print where group=full or group=write or group=read

# Check live sessions and their transports
/user active print

# Export the user/group configuration for diffing (store securely)
/user export terse

Two audit signals deserve escalation: any human account in full (other than a sealed break-glass identity), and any account whose group includes policy without a documented justification. Because policy allows creating users, a single compromised policy account can persist by minting a new backdoor identity — which is why user-management rights should be rarer than configuration-write rights.

9. Common mistakes checklist

1. Treating read as read-only. It includes reboot, sniff, sensitive, password, and API access.
2. Granting write without read. The user can change state but cannot see what they changed.
3. Using set policy=read to restrict an existing group. Use !policy or restate the full set.
4. Granting policy without write. Produces an unusable user-admin role.
5. Leaving ftp enabled for convenience. Cleartext transport plus file deletion.
6. Shared accounts. Destroys accountability and makes session revocation indiscriminate.
7. No source-address restriction. Leaves credentials usable from anywhere.
8. RADIUS default-group=read. Silently grants the dangerous built-in role when the server misbehaves.
9. Changing a group and not killing sessions. Old privileges can outlive the policy change.
10. Assuming policy lists are identical across RouterOS versions. rest-api, dude, and tikapp differ by release; verify on-device.

10. Frequently asked questions

Can a MikroTik user belong to more than one group?

No. Each user is assigned exactly one group, and that group’s policy set is the user’s complete authorisation. Composite roles must be modelled as custom groups that merge the required policies.

Is the built-in read group safe for a monitoring system?

No. It includes reboot, sniff, sensitive, password, api, and rest-api. Create a custom group containing only read, test, and the specific transport the monitor uses.

What is the difference between the api and rest-api policies?

api grants access through the binary API; rest-api grants access through the REST API. They are separate flags in v7 and should be granted independently. Some field reports note that REST calls may still require the api policy on certain builds, so validate against your release.

Why can a user still see a password after I removed sensitive?

They most likely have write and are changing the value rather than reading the stored secret, or they are using a transport whose output is not masked by the sensitive flag. Verify with /user group print detail and test the exact command path they are using. The sensitive policy governs display and export of sensitive fields, not write access to every secret-bearing object.

Does changing a group’s policy affect users who are already logged in?

Not reliably. Established sessions can retain the authorisation they were created with. After any RBAC change, list sessions with /user active print and force re-authentication with /user active remove (or the older request-logout form).

What happens if the RADIUS server is unreachable?

Local users still authenticate, because RADIUS is only consulted when the username is not in the local database. This is the operational justification for maintaining a local break-glass full-access account.

Conclusion

MikroTik’s RBAC model is simple — one user, one group, a set of capability flags — but the default groups obscure that simplicity with overly broad permissions. The productive pattern is consistent: build custom groups from explicit policy lists, deny sensitive, sniff, and policy by default, bind accounts to source addresses, use SSH keys and inactivity lockouts, restrict the management services that are reachable at all, and centralise authorisation through RADIUS with an exclude-groups safety net. Then verify the whole thing on a schedule, because RBAC that is not audited is just documentation of what you once intended.

Check our list of MikroTik guides