How to Audit Read-Only Accounts on a Management Portal

To audit read-only accounts on a management portal, export every user and API key, match each one to a named owner and a current business need, and disable anything nobody claims. Then check what each remaining account actually did, restrict where it can log in from and set a review date. Read-only accounts deserve this attention because bugs such as the October 2026 VeloCloud Orchestrator zero-day turned the lowest read-only role into full platform control.

Why audit read-only accounts at all?

Read-only accounts are worth auditing because a vulnerability can turn any authenticated session into an administrator, and read-only logins are the least watched sessions on most portals. They are created freely, shared often and almost never removed.

The usual assumption is that a read-only user can look but not touch. That holds only while the portal's authorization code is correct. When it is not, the read-only role becomes the attacker's starting point. Arista's advisory for VeloCloud Orchestrator CVE-2026-114625 names Enterprise Read Only, the lowest built-in tenant role, as the minimum needed to escalate to a superuser operator. CVSS 3.1 scored it 9.9.

Where read-only accounts come from

Before you audit, know where to look. Read-only access on network and security consoles usually comes from:

• Auditors and assessors given temporary access that was never revoked
• NOC and help desk staff who need dashboards but not configuration rights
• Managed service providers and resellers with partner-level logins
• Monitoring and reporting integrations using API tokens or service accounts
• Former employees whose directory account was disabled while the local portal account was not

Local accounts are the biggest gap. Single sign-on removes a leaver everywhere at once, but a local account on an appliance or orchestrator survives until someone deletes it.

How do you audit read-only accounts step by step?

Export every account and token from the portal, assign each one an owner, remove the unclaimed ones and review what the rest did recently. Repeat the review on a fixed schedule and after every security advisory for that product.

1. Export the full user list. Include local users, SSO-mapped users, partner and delegated accounts, and API tokens. Record role, creation date, last login and authentication method for each. Most portals offer this in the user administration page or through their API; if yours does not, capture it manually and note the gap.
2. Assign an owner to every account. Each account needs a named person who can say why it exists. Service accounts need an owning team and the system that uses them.
3. Disable what nobody claims. Disable first, then delete after a waiting period, so a forgotten integration fails loudly instead of silently.
4. Check last login against need. An account that has not logged in for 90 days rarely needs to exist. An auditor account from last year's assessment almost certainly does not.
5. Look for shared credentials. Generic names such as "noc", "readonly" or "monitor" usually mean several people know the password. Replace them with named accounts.
6. Review recent activity. Pull the portal's audit log for every read-only account. Any configuration change, user creation or role change made by a read-only identity is an incident, not a quirk.
7. Restrict where accounts can log in from. Limit the portal to administrative networks, and limit API tokens to the source addresses of the systems that use them. This is the mitigation Arista recommends for VCO, and it is covered in more depth in our guide on finding admin consoles reachable from the internet.
8. Require MFA or SSO for every interactive account, read-only included.
9. Record the result with the date, the reviewer and the accounts removed, and set the next review date.

What should you look for in the audit logs?

Look for read-only accounts doing things their role does not permit, logging in from unfamiliar addresses or at unusual hours, and sending far more requests than a person would. Any one of those is reason enough to preserve logs and open an investigation.

Specific signals to check:

• Configuration changes, new users or role changes attributed to a low-privilege account
• Logins from addresses outside your administrative networks, or from addresses a vendor advisory lists as malicious
• Bursts of requests, or requests with unusual encoded characters and path components, which Arista lists as signs to look for in VCO web access logs
• An account that suddenly becomes active after months of silence

If you find any of these, keep the logs before you change anything. The order matters, as explained in how to preserve evidence before patching.

How often should you review management portal accounts?

Review management portal accounts at least quarterly, and run an extra review whenever the vendor discloses an exploited vulnerability that requires authentication. Also review when a contract with an MSP, auditor or reseller ends.

A product with a history of emergency patches deserves a tighter cycle. Our piece on why repeat zero-days in one product need a different plan explains how to set that cadence.

Make the audit stick

The audit is only useful if the next one finds less. Three habits help:

• Create accounts with an expiry date wherever the portal supports it, especially for auditors and contractors.
• Prefer SSO over local accounts so leavers lose access when their directory account is disabled.
• Keep an inventory of management portals. You cannot audit a console you have forgotten about. Orchestrators such as the one described in what an SD-WAN orchestrator is often belong to the network team and never appear in the identity team's reviews.