How do organisations measure whether third-party remote access controls are actually working?

Why This Matters for Security Teams

Third-party remote access is only effective when it can be proven, not assumed. Security teams need evidence that vendor and contractor access is time-bound, tightly scoped, and fully observable across every session. That means measuring whether privileged access is actually removed when work ends, whether session activity is recorded, and whether exceptions are rare enough to justify. The issue is not policy language; it is whether the control stops standing access from becoming standing risk.

NHIMG research shows the scale of the problem: only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs. Even though that statistic focuses on non-human credentials, the operational lesson applies directly to third-party access: if revocation is weak, measurement will expose it quickly. Mature programs also align their evidence with control baselines such as the NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10.

In practice, many security teams discover control failure only after a vendor account remains active long after the engagement has ended.

How It Works in Practice

Effective measurement starts with three questions: who got access, for what purpose, and for how long. Organisations should define these as audit-able control objectives, then test them against real sessions, not ticket metadata. The best evidence comes from identity and session telemetry that shows approval, issuance, use, and revocation in one traceable chain. Current guidance suggests combining privileged access management with continuous logging, just-in-time access, and exception tracking so the control can be measured as an operating process, not a one-time approval.

At minimum, security teams should collect:

• Time to grant and time to revoke access for each third party.
• Percentage of sessions that used short-lived or just-in-time credentials.
• Session coverage, including video, command, or API activity logs where applicable.
• Number and age of standing exceptions, broken down by vendor, system, and business owner.
• Evidence that access was limited to approved systems, data sets, and maintenance windows.

Measurement works best when access is tied to a named sponsor and a defined business outcome. That makes it possible to compare requested access against actual use and detect over-privilege. It also helps identify controls that are technically enabled but operationally ignored, such as shared vendor accounts, stale approvals, or emergency access that never expires. NHIMG’s 52 NHI Breaches Analysis shows how quickly weak identity governance becomes an incident pattern, while the Ultimate Guide to NHIs — Key Challenges and Risks is useful for mapping control gaps to remediation priorities. These controls tend to break down in distributed contractor environments because access is granted through multiple tools, but revocation is only enforced in one of them.

Common Variations and Edge Cases

Tighter third-party access controls often increase operational overhead, so organisations have to balance assurance against support burden. That tradeoff becomes visible in edge cases such as emergency access, managed service providers, and legacy systems that cannot natively support short-lived credentials or full session recording.

Best practice is evolving, and there is no universal standard for every vendor model. For example, some environments measure control effectiveness by percentage of access requests approved within policy, while others prioritise revocation latency or the share of sessions covered by monitoring. The right metric depends on whether the main risk is over-approval, weak oversight, or delayed deprovisioning. A useful rule is that any access path without revocation evidence should be treated as incomplete control, even if it was initially approved.

Teams should also watch for these exceptions:

• Shared service accounts, which can make attribution impossible even when sessions are logged.
• Long-running maintenance windows, where valid access may look like standing access unless TTL is enforced.
• Break-glass accounts, which often bypass normal workflow and require separate measurement.
• Third-party tools that proxy access, where the real session owner is hidden unless logs are normalized.

For broader governance alignment, the control evidence should map to frameworks such as CIS Controls v8 and ISO/IEC 27001:2022 Information Security Management. The practical test is simple: if the organisation cannot prove revocation, session scope, and accountable ownership for every third party, the control is not yet working as intended.

Related resources from NHI Mgmt Group

• How do organisations know whether just-in-time database access is actually working?
• How can organisations tell whether OT access controls are actually working?
• How do organisations know whether their access management controls are actually working?
• How do organisations know whether cloud access controls are actually working?