Should organisations treat contractor and third-party accounts differently in Cyber Essentials reviews?

Why contractor and third-party accounts should be reviewed as one access population

Cyber Essentials reviews are meant to reflect actual access, not internal org charts. Contractor, supplier, partner, and outsourced support accounts often authenticate differently, use separate browsers or endpoints, and carry a distinct offboarding path, but they still create the same exposure if they can reach business systems. Treating them separately is where blind spots start.

That is why externally managed accounts should be counted in the same review population as staff accounts, then assessed for sponsor ownership, business need, and expiry. A separate label does not make them a separate risk class if they can log in, hold privileges, or access the same data.

What changes when an account is external to the organisation?

The account is often created, used, and retired under different operational assumptions. The organisation may not control the user’s device, password hygiene, browser state, or local session persistence, and it may have less visibility into how the account is actually used day to day. That makes the review question less about employment status and more about control boundary.

In practice, the same identity can be higher risk when it is externally managed because the account may be shared across projects, kept alive past the work end date, or used through a federated path that looks legitimate but bypasses normal corporate endpoint controls. The access path matters as much as the account label.

For third-party access models and governance patterns, see Third-Party, B2B and Contractor Access Guide and the broader identity control baseline in IAM and IGA Basics.

How to review external accounts without creating false comfort

Start with inventory, then ask whether the account is sponsored, time-bound, and tied to a named business owner. Reviews should confirm that access still has a current business purpose, that the entitlement matches the task, and that any federation, shared mailbox, or vendor portal access is still needed. If the answer depends on an external manager, verify the control with evidence rather than assumption.

Reviews should also look for drift between the access method and the review record. A contractor may be approved as a named user, while the real access path is a shared vendor account, a long-lived token, or a local credential on an unmanaged laptop. When that happens, the review passes administratively but fails operationally.

NHIMG’s Top 10 NHI Issues is useful here because many external-access failures show up as the same patterns of sprawl, over-privilege, stale access, and weak offboarding.

When contractor and third-party accounts become a material review risk

The risk rises when external accounts are excluded from recertification, reviewed only by list membership, or left without an expiry date. That creates a clean policy report while leaving live access in place. It also increases the odds that a stolen external credential, reused login, or forgotten supplier account becomes an easy entry point into internal systems.

Externally managed accounts also tend to carry more third-party dependency risk. If the vendor’s own access governance is weak, the organisation can inherit over-privilege, delayed revocation, or poor session discipline without seeing it directly. Those are review failures as much as they are technical failures.

For incident patterns that show how third-party access turns into real compromise, Scania insurance portal breach 2025 and Marks and Spencer cyberattack 2025 are both strong reminders that external-user handling is not a paperwork issue.

Risk and Threat Considerations

External accounts are attractive because they often sit outside normal corporate controls, yet still reach sensitive systems. If they are excluded from review cycles, the organisation can retain dormant access, miss unmanaged sign-in methods, or overlook a compromised vendor login that is still trusted by the target environment.

Failure mechanism: The review process counts the account as “third party” and therefore outside scope, while the actual access path remains live, privileged, and insufficiently governed. Attackers or careless users then exploit that control gap through stale access, shared credentials, or unmanaged session reuse.

Impact: Organisations can lose visibility into who can reach production systems, fail to revoke access after work ends, and create a straightforward route for data theft or account takeover without any policy exception appearing in the review output.

Practitioner Guidance

What to verify: Confirm that contractor and third-party accounts appear in the same recertification population as employee accounts, even if the approval workflow is different. The review should show owner, sponsor, expiry, and current business purpose for each external identity.

Decision rule: If an externally managed account can authenticate to a business system, treat it as in-scope for access review and offboarding controls. If the access cannot be tied to a named sponsor or a time-bound need, escalate it as an exception rather than accepting it as “vendor-owned”.

Practitioner takeaway: The key judgement is not whether the user is employed by you, it is whether the access is still active, justified, and revocable under your control.

Related resources from NHI Mgmt Group

• When should organisations treat third-party cyber ratings as part of vendor risk governance?
• When should organisations treat third-party integrations like privileged accounts?
• When should organisations treat an NHI as a high-priority risk?
• Should organisations treat AI vendors like third-party suppliers?