Monitoring Platform Credentials: Securing Polling Accounts

Network and application monitoring tools hold a credential for almost every system they watch, and those polling accounts are often domain administrators, root SSH keys and cloud read-all roles because that was the quickest way to make the graphs work. A network management system (NMS), infrastructure monitor or application performance monitoring (APM) platform logs in to servers over WMI, WinRM and SSH, to network devices over SNMP and APIs, to databases, hypervisors and cloud accounts. When the platform is compromised, every one of those credentials is too: after the SolarWinds Orion compromise, CISA directed US federal agencies to reset all credentials used by or stored in the software and to treat them as compromised. This guide covers how to inventory, scope, store, rotate and monitor polling credentials across Windows, Linux, network, database and cloud targets. It is for monitoring platform owners, infrastructure teams and identity teams. SNMP itself is covered in depth in the SNMP Security Guide.

Key takeaways

Polling rarely needs administrator rights. Windows has built-in groups and WMI namespace permissions for read-only monitoring, Linux supports restricted SSH keys, and cloud providers publish view-only roles.
The monitoring server is a credential vault. Treat its database, encryption keys, collectors and backups as you would a privileged access system.
One credential per target class, not one for everything. Separate Windows, Linux, network, database and cloud credentials, and separate production from non-production, so one leak does not open the whole estate.
Plan for "reset everything". If the platform is compromised you will need to rotate every stored credential quickly; you can only do that if you know what they are and where they are used.
Watch the polling accounts themselves. A monitoring account logging on interactively, from a host that is not a collector, or doing anything other than reading is a high-confidence alert.

What monitoring platforms hold

Target	Typical protocol	Credential held	Common over-privilege
Windows servers	WMI over DCOM, WinRM (WS-Management), performance counters, event logs	Domain or local user password	Member of Domain Admins or local Administrators everywhere
Linux and Unix servers	SSH commands, agents	SSH private key or password	root login or unrestricted sudo
Network devices	SNMP, SSH, vendor APIs	SNMP community strings or SNMPv3 users, device logins, API tokens	Read-write SNMP communities; privilege 15 device logins for config backup
Databases	Native client connections	Database logins	sysadmin or DBA role instead of view-state permissions
Hypervisors and storage	Management APIs	API users	Full administrator role
Cloud accounts	Cloud APIs	Access keys, service principal secrets, cross-account roles	Read-all or contributor roles that can read stored data
Applications (APM, synthetic tests)	Agents, HTTP checks	Agent ingest keys, test user passwords, API tokens	Real user accounts used for synthetic logins

Credentials sit in the platform's database and configuration, on remote collectors or pollers, and sometimes in scripts and custom checks. Each of those is a place an attacker who reaches the platform can read them.

Least privilege by target

Windows

Microsoft documents built-in groups that provide monitoring access without administrator rights. Use them before reaching for Administrators.

Built-in group	What Microsoft documents it allows	Monitoring use
Performance Monitor Users	Monitor performance counters locally and from remote clients without being an administrator	CPU, memory, disk and service counters
Performance Log Users	Manage performance counters, logs and alerts locally and remotely without being an administrator	Only if the tool schedules data collector sets
Event Log Readers	Read event logs from local computers	Event log collection
Remote Management Users	Access WMI resources over WS-Management via WinRM, only in namespaces that grant the user access	WinRM-based polling
Distributed COM Users	Launch, activate and use DCOM objects on the computer	Classic WMI over DCOM

WMI namespace permissions: per Microsoft's guidance on remote WMI connections, a non-administrator needs DCOM Remote Launch and Remote Activation and the Remote Enable permission on the specific WMI namespace (by default enabled only for administrators). Grant Remote Enable on the namespaces the tool reads, not on root and all children by default.
Packet privacy: request the PktPrivacy authentication level for remote WMI so queries and results are encrypted; Microsoft notes namespaces can be set to require it.
Deploy by Group Policy: add the monitoring group to these built-in groups through restricted groups or Group Policy Preferences so membership is consistent and auditable.
Service status checks: some checks query the Service Control Manager. Grant read access to the specific services rather than adding the account to Administrators. Test what your tool actually needs in a pilot.
Prefer managed identities: if the collector runs as a Windows service, run it as a gMSA so there is no stored password. See the Group Managed Service Accounts (gMSA) Guide.

Linux and Unix

Dedicated non-root user on each host, with an SSH key unique to the monitoring platform (ideally unique per collector).
Restrict the key in authorized_keys: the OpenSSH restrict option disables forwarding, PTY allocation and ~/.ssh/rc; from= limits the key to collector addresses; command= forces a single wrapper script; expiry-time= sets a hard end date.
Narrow sudo: where a check needs root (for example reading a protected log), allow that one command with fixed arguments in sudoers, never ALL.
Use certificates where available: SSH user certificates with short validity remove long-lived keys. See the Linux Service Accounts and Keytab Management Guide.

Network devices

SNMPv3 with authPriv, read-only views, one user per monitoring system, and access lists limiting which collectors may poll. Remove read-write communities. See the SNMP Security Guide.
Configuration backup accounts need read access to the running configuration, which often contains other secrets. Give them a dedicated AAA role, log every session and keep them separate from polling. See the Network Device Management Plane Hardening Guide.

Cloud

Cloud platforms are listed alphabetically; the order is not a ranking.

AWS: AWS documents that the ReadOnlyAccess managed policy can read data in storage services such as S3 buckets and DynamoDB tables, while ViewOnlyAccess lists resources and basic metadata without reading content. Start from ViewOnlyAccess (or a custom policy) for inventory and metrics polling, and use cross-account roles rather than access keys.
Azure: Microsoft's Azure Monitor documentation describes Monitoring Reader (view monitoring data, change nothing) and Monitoring Contributor (also change monitoring settings). Assign Reader at the narrowest scope, never grant ListKeys at subscription scope, and prefer read-only SAS or listen-only Event Hubs keys for data consumers.
All clouds: use workload identity federation where the platform supports it, so no static secret is stored. See How to replace Azure app secrets with federated credentials.

Protecting the platform that holds the credentials

Tier it correctly: if the monitoring platform holds a credential that can administer domain controllers, it is in the same tier. Removing that privilege is better than protecting it.
Credential store: find out how the platform encrypts stored credentials and where the key lives. Restrict database access to the application service and encrypt backups.
Vault integration: where the platform can retrieve credentials from a secrets manager at poll time, use it, and scope the platform's vault identity to monitoring secrets only. See the Secrets Management Guide.
Collectors: remote pollers often cache credentials locally. Harden them as servers in their own right, restrict outbound connections to the targets they poll and the central server.
Administrator access: SSO with MFA for the console, separate roles for viewing dashboards and managing credentials, and API tokens scoped and expiring. Dashboard users should never be able to reveal stored credentials.
Supply chain: monitoring agents and updates run with high privilege on every host. Verify update signatures and restrict the platform server's outbound internet access to the vendor endpoints it needs. The SolarWinds supply chain compromise showed how a trusted, widely deployed monitoring product can become a starting point; the customer-side lesson is that monitoring service accounts should not hold domain or cloud administrator rights.

Rotation and the "reset everything" plan

CISA's Emergency Directive 21-01 required agencies to "reset all credentials used by or stored in SolarWinds software" and to consider them compromised. Its later supplemental guidance asked agencies rebuilding affected devices to rotate every account credential and other secret tied to the device, including SNMP strings, to use MFA where possible and, where not, randomly generated passwords longer than 25 characters rotated at least every 90 days, with service accounts given minimum privilege. Whatever platform you run, prepare to do the same quickly.

Keep a credential register for the platform: each stored credential, its target class, the systems that accept it, its owner and how to rotate it.
Script rotation per class (Windows, Linux keys, SNMPv3 users, database logins, cloud keys) so it can run in hours, not weeks. Test it on non-production first.
Rotate on a schedule where credentials are static: our suggestion is 90 days for passwords and SNMP secrets, aligned with the CISA rebuild guidance, and on every platform administrator departure.
Rotate on suspicion of the platform, its collectors or its vendor update channel, and on any advisory affecting your version. Apply vendor security updates promptly.
Verify after each rotation that polling succeeds and that the old credential is rejected.

For per-account mechanics, see Credential Rotation at Scale.

Detection and measurement

Signal	Source	Meaning
Monitoring account interactive or remote desktop logon	Windows 4624 logon type 2 or 10	Credential used by a person or attacker
Monitoring account authenticating from a non-collector host	Windows 4624/4768 source address, Linux auth logs, cloud sign-in logs	Stolen credential
Monitoring account performing writes	Directory audit, cloud audit logs, database audit	Privilege abuse or over-privilege
Credential viewed or exported in the platform	Platform audit log	Insider or compromised console account
SNMP authentication failures or polls from unknown sources	Device logs and traps	Credential guessing or rogue poller

Privilege: number of monitoring credentials with administrator, root, sysadmin or cloud write rights (target zero).
Uniqueness: percentage of target classes and environments with their own credential.
Rotation: percentage of stored credentials rotated within policy, and time to rotate all of them in your last exercise.
Vaulting: percentage of credentials retrieved from a vault or replaced by federation.
Alert coverage: percentage of monitoring accounts with source-restriction alerts in the SIEM.

Rollout plan

Export and classify every credential in the platform and its collectors; map each to its rights in the directory, on hosts and in clouds.
Pilot least privilege on one target class (for example Windows file servers) with the built-in groups and namespace permissions above; compare data completeness against the old account for a full reporting cycle.
Roll out by ring, keeping the old credential available but unused for one cycle so you can roll back a ring by switching the credential profile.
Remove the old privileged accounts once rings are stable, and add detection rules.
Move to vault or federation and test the reset-everything plan annually.

Small organisations with a single monitoring server can complete this in weeks: the biggest win is removing Domain Admins and root. Large organisations with several tools (NMS, APM, log collectors, cloud posture) should apply the same register and standards to each and avoid one team's tool becoming the exception.

Common failure patterns

Domain Admin for WMI: granted at install because remote WMI failed with access denied, never revisited.
One root key on every Linux host, unrestricted, copied to every collector and a few administrators' laptops.
Read-write SNMP communities left on devices "for the monitoring tool" that only ever reads.
Cloud read-all roles that can read storage contents when the tool only needs inventory and metrics.
Synthetic checks using real staff accounts, which break on leaver processing and give the platform a human's access.
No rotation plan: after a platform advisory, nobody knows which credentials it held, so rotation takes months.

Framework mapping

Framework	Reference	Monitoring credential control
NIST SP 800-53 Rev. 5	AC-6 Least Privilege	Built-in groups, namespace rights, restricted keys, view-only cloud roles
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; SC-28 Protection of Information at Rest	Rotation and protection of the credential store
NIST SP 800-53 Rev. 5	AC-2 Account Management; SI-4 System Monitoring	Owned polling accounts with source-restriction alerts
NIST CSF 2.0	PR.AA-01 credentials for services managed; PR.AA-05 least privilege	Credential register and scoped accounts
MITRE ATT&CK v20	T1555 Credentials from Password Stores; T1078.002 Domain Accounts	Platform store theft and reuse of polling accounts
MITRE ATT&CK v20	M1026 Privileged Account Management	Removing administrator rights from polling accounts

For hardening the monitoring server itself (operating system, web console and network exposure), see our Monitoring Server Hardening Guide; this guide covers the credentials the platform holds.

Practitioner checklist

Export every credential held by the monitoring platform and collectors into a register with owner and rotation method.
Remove Domain Admins, local Administrators, root and cloud write roles from polling accounts.
Use Performance Monitor Users, Event Log Readers, Remote Management Users and WMI Remote Enable on specific namespaces for Windows polling.
Restrict Linux monitoring keys with restrict, from= and command=, and limit sudo to named commands.
Use SNMPv3 authPriv read-only views and remove read-write communities.
Use view-only cloud roles at narrow scope and federation instead of static keys.
Separate credentials per target class and environment.
Alert on monitoring accounts logging on interactively, from non-collector hosts, or making changes.
Script and rehearse a full credential reset for the platform at least annually.

Monitoring Platform Credentials: Securing the Polling Accounts Your NMS and APM Tools Hold