MikroTik Manager — Security Whitepaper

1. Architecture Overview

MikroTik Manager is a fully self-hosted network management application distributed as a Docker container. It runs entirely within the customer's own infrastructure.

2. Data Residency & Privacy

Aspect	Detail
Data storage	Local SQLite database inside Docker volume
Data location	Customer's server only — no cloud, no external storage
Telemetry	NONE — no usage data, analytics, or crash reports
Phone-home	NONE — no fleet, device, configuration, or usage data ever leaves your server
License activation	Offline — validated locally, no external server contact
Device connections	Managed MikroTik devices within the customer's network
Optional outbound	Read-only, GET-only fetches of public feeds — never carry any of your data. (1) RouterOS CVE feed from NVD; (2) latest RouterOS version from MikroTik; (3) Manager update check from GitHub Releases. Each can be disabled; all degrade gracefully with no internet (last known data is kept).
Config backups	Stored in the local database

3. Authentication & Authorization

3.1 User Authentication

JWT-based authentication — short-lived access tokens (15 min) + refresh tokens (7 days)
bcrypt password hashing — passwords are never stored in plaintext
Automatic token refresh on expiration
Two-factor authentication (TOTP) — optional per-user RFC 6238 TOTP via any authenticator app (Google Authenticator, Authy, 1Password, Microsoft Authenticator). Secrets are encrypted at rest with AES-256-GCM; 8 single-use backup codes (bcrypt-hashed) are issued at enrolment. Admin reset endpoint clears 2FA on lost devices
Passkey / WebAuthn / FIDO2 (v1.28.0+) — additive second factor alongside TOTP. Apple/Google passkey, Touch ID, Face ID, Windows Hello, YubiKey. Multi-credential per user (each named at registration, with last-used timestamp). Counter regression check on every assertion (any non-zero counter decrease fails closed — possible cloned authenticator). Stored public keys only, no secrets. Admin reset endpoint clears all of a user's passkeys. Requires HTTPS on a real domain — the WebAuthn spec forbids IP addresses as RP IDs, so LAN-IP installs explicitly show the feature as Unavailable with a configuration hint rather than failing silently
Refresh tokens invalidated on password change — refresh tokens carry the password-change timestamp; the refresh endpoint rejects any token issued before the user's most recent password update
Auto-generated secrets on fresh installs — JWT_SECRET and ENCRYPTION_KEY are auto-generated and persisted to data/.secrets.json (file mode 0600) when not supplied via environment, eliminating the public-default risk
Admin auto-seed only on empty database — the default admin/admin user is created once on first install; deleting it does not re-seed on the next restart

3.2 Role-Based Access Control

Role	Capabilities
Super Admin	Full access plus user management and per-site access grants — the only role that can manage users and assign sites
Admin	Device CRUD, commands, upgrades, service toggles
Operator	Device management, command execution, upgrades, backups
Viewer	Read-only: dashboard, device status, interface views

Each non–Super Admin role can additionally be scoped to specific sites (per-site RBAC, v1.33.0+): the role decides what a user can do, the assigned site list decides where. A scoped user only ever sees and acts on their sites — across the dashboard, device list, sites, logs, backups, live status updates, and bulk commands/upgrades — enforced server-side at the data and WebSocket layers, not just in the UI. Users with no scope restriction retain full-fleet access.

3.3 Device Credential Security

Device passwords encrypted at rest using AES-256-GCM
Each encrypted value uses a unique initialization vector (IV)
Encryption key configurable via environment variable
Credentials decrypted only in memory at the moment of device communication

Recommended: create a dedicated MikroTik user group with minimal policies:

/user/group/add name=manager-group policy=ssh,reboot,read,write,sensitive,rest-api,policy,!local,!telnet,!ftp,!test,!winbox,!password,!web,!sniff,api,!romon

4. Network Security

4.1 Transport Encryption

HTTPS/TLS — optional TLS server on port 3443
WebSocket Secure (WSS) — automatic over HTTPS
Supports custom certificates or auto-generated self-signed
HTTP and HTTPS can run in parallel for migration

4.2 Device Communication

Method	Protocol	Encryption	Use Case
SSH	TCP/22	Encrypted	Default, best compatibility
REST API	HTTPS/443	TLS	RouterOS 7.1+
SNMP	UDP/161	SNMPv2c	Monitoring only, no write ops

4.3 Network Exposure

No inbound connections required from outside the network
No outbound connections that carry your data — the Manager never transmits fleet, device, configuration, or usage information off the server
Optional read-only public-feed checks (RouterOS CVE feed from NVD, latest RouterOS version from MikroTik, Manager update from GitHub Releases) — GET-only, no request body, individually disable-able, and they degrade gracefully when offline
Designed to run behind a reverse proxy for production

5. Data Protection

Encryption at Rest

Data	Protection
Device passwords	AES-256-GCM with unique IV per value
User passwords	bcrypt hash (irreversible)
TOTP secrets	AES-256-GCM (same key as device passwords)
2FA backup codes	bcrypt hash (irreversible), single-use
Device configs	Local SQLite — OS-level file permissions
JWT & encryption secrets	Auto-generated on fresh install, persisted to `data/.secrets.json` (mode 0600); env vars take priority when set

Encryption in Transit

Channel	Protection
Browser ↔ Manager	HTTPS/TLS (recommended for production)
Manager ↔ MikroTik (SSH)	SSH protocol encryption
Manager ↔ MikroTik (REST)	HTTPS/TLS
WebSocket	WSS when TLS enabled

6. Container Security

Base image: node:22-alpine — minimal attack surface
Multi-stage build — build dependencies excluded from final image
Non-root execution — runs as non-privileged user
Minimal packages — Alpine-based with no extras
No privileged flags — no host network access required
Only required ports exposed (3000 HTTP, 3443 HTTPS)
Data persistence via Docker volume mount

7. Dependency Management

Runtime dependencies pinned in package-lock.json
No third-party SaaS, SDK, or tracking dependencies — core operation is fully self-contained. The only outbound traffic is the optional read-only public-feed checks described in §2 / §4.3 (NVD, MikroTik, GitHub Releases), which carry none of your data and can be disabled
Key dependencies: express, better-sqlite3, node-ssh, net-snmp, jsonwebtoken, bcrypt, ws

8. Supply Chain Security

MikroTik Manager minimizes supply chain risk through controlled dependencies, reproducible builds, and a fully self-contained distribution model.

8.1 Docker Image Integrity

Official base image — built on node:22-alpine from Docker Hub official library
Multi-stage build — build tools and dev dependencies are excluded from the final image
Immutable tags — each release is tagged with a specific version (e.g., v1.17.0), never overwritten
GitHub distribution — images distributed via GitHub Container Registry (ghcr.io), tied to the official repository

8.2 Dependency Controls

Locked dependencies — package-lock.json ensures reproducible installs with exact versions and integrity hashes
Minimal dependency tree — only essential runtime packages, no unnecessary transitive dependencies
No post-install scripts — no npm lifecycle scripts that execute arbitrary code during installation
No CDN or external assets — all frontend assets bundled locally, no runtime fetches from third-party servers

8.3 Build Process

Reproducible builds — identical source + lockfile produces identical output
No remote code execution — the build process does not download or execute code outside of pinned npm packages
Single author — all code written and reviewed by the maintainer, no external contributors with commit access

8.4 Runtime Isolation

No auto-updates — the application never downloads or applies updates by itself
No plugin system — no mechanism for loading external code at runtime
No outbound connections — the container makes zero network calls outside the customer's network

9. OWASP Top 10 Coverage

A01

Broken Access Control

RBAC with three roles, JWT middleware on all API routes

A02

Cryptographic Failures

AES-256-GCM for secrets, bcrypt for passwords, TLS support

A03

Injection

Parameterized SQLite queries, input validation

A04

Insecure Design

Principle of least privilege for MikroTik user groups

A05

Security Misconfiguration

Secure defaults, configurable via environment variables

A06

Vulnerable Components

Alpine-based image, pinned dependencies

A07

Auth Failures

JWT with short expiry, bcrypt, role enforcement, refresh-token invalidation on password change, optional TOTP 2FA, optional WebAuthn / passkey (v1.28.0+)

A08

Data Integrity Failures

No external code execution, no untrusted deserialization

A09

Logging Failures

Structured logging, no sensitive data in logs

A10

SSRF

No user-controlled outbound requests, device IPs validated

10. Deployment Recommendations

1

Use HTTPS — enable TLS or deploy behind a TLS-terminating reverse proxy

2

Change the default admin/admin password immediately after first login. Delete the admin account once a named admin exists — it will not be re-created.

3

Back up data/.secrets.json alongside the database — secrets are auto-generated on fresh installs and losing this file invalidates all sessions and makes encrypted device passwords unrecoverable. To override or rotate, set JWT_SECRET / ENCRYPTION_KEY via environment (openssl rand -hex 48 / -hex 32).

4

Network segmentation — deploy in the management VLAN with MikroTik devices

5

Restrict access — firewall rules to limit access to management interface

6

Regular backups — back up data/mikr.db per your backup policy

7

Keep updated — apply updates for security fixes

8

Minimal MikroTik permissions — use the recommended limited user group

11. Compliance Notes

Requirement	Status
Data sovereignty	Full — all data stored locally, no cloud
GDPR	No personal data processed beyond user account names
Network isolation	Supported — core management runs fully in air-gapped environments; the optional public-feed checks (CVE / version / update) simply stay idle with no errors
Audit trail	Command history with user attribution and timestamps
Access control	Role-based with three permission levels

12. Vulnerability Reporting

To report a security vulnerability, contact: ihor@hreskiv.pl

We take security reports seriously and will respond within 48 hours.