Security checklist

This checklist is a practical baseline for people who administer and use RMON. Adapt it to your organization's security policy and network design.

First login

• Change the initial administrator password immediately and use a unique, long password.
• Open RMON through HTTPS with a certificate trusted by your users' browsers.
• Limit access to the RMON interface to the users and networks that need it.
• Set the correct time zone and time synchronization so check history and security events have reliable timestamps.
• Keep a separate administrator account for administration; use a lower-privilege account for routine monitoring work.

Users, groups, and access

• Create an individual account for each person. Do not share administrator credentials.
• Give each user the lowest role that allows them to do their job.
• Use groups to separate teams, environments, or customers and verify group ownership for servers, agents, channels, and checks.
• Disable or remove accounts promptly when a person no longer needs access.
• Review privileged users and group membership on a regular schedule.
• If your organization uses a directory service, prefer the secure directory connection option and apply the same access-review process.

See Groups and roles for the user workflow.

Connections and credentials

• Prefer SSH keys over passwords and use a dedicated account for RMON-managed server access.
• Grant that account only the permissions required for the actions your team performs.
• Do not reuse personal, root, or production application credentials for monitoring.
• Restrict who can view or edit SSH credentials, HTTP authentication, proxy credentials, and mTLS key material.
• Use separate credentials for different environments or trust boundaries so one disclosure has limited impact.
• Rotate credentials regularly and immediately after a suspected disclosure or personnel change.

Checks and integrations

• Never place passwords, tokens, private keys, or customer data in check names, descriptions, groups, or runbook labels.
• Use the dedicated password, authentication, certificate, proxy, and channel fields for sensitive values.
• Keep Ignore TLS/SSL errors disabled. Enable it only for short, controlled diagnostics and turn it off afterwards.
• Give monitoring credentials read-only access whenever a read-only check is sufficient.
• Treat notification tokens, webhooks, and integration keys as secrets. Test the destination after creation and after rotation.
• Delete unused channels and remove old integrations at the provider as well as in RMON.
• Check request bodies and headers before saving them to make sure they contain no unnecessary personal or confidential data.

See Notifications and alerting for channel setup and testing.

Status pages and runbooks

• Treat every status-page URL as public. The slug is an address, not a password.
• Use public-friendly check names and avoid internal hostnames, IP addresses, group names, or customer identifiers.
• Link alerts only to runbooks that the intended responders are authorized to open.
• Do not put credentials or temporary access links in runbook URLs.
• Open each published status page while signed out and review everything visible, including response charts.

Use the Status pages guide before publishing or changing a page.

Routine review

• Keep RMON on a supported, current release and review the changelog before updating.
• Review History and internal logs for unexpected administrative changes or repeated failures.
• Confirm that all agents, servers, checks, channels, users, and status pages still have an owner and a business purpose.
• Test critical notification channels on a regular schedule.
• Review temporary checks and expiration dates; remove data that is no longer needed.
• Document who can approve access, publish a status page, and rotate an integration credential.

If a secret is exposed

1. Disable or revoke the exposed credential at its source.
2. Create a replacement with the minimum required access.
3. Update the corresponding RMON credential, check, or notification channel.
4. Use Test or run the affected check to confirm that the replacement works.
5. Review RMON history, provider activity, and affected systems for unauthorized use.
6. Remove the secret from descriptions, runbooks, tickets, or messages where it was exposed.