How to limit the blast radius of third-party access

A contractor needs access to your staging environment and an API credential to build an integration.

You grant access. The integration ships, the project ends, and you disable the contractor's account.

But what about the API key they copied three weeks ago?

This is where contractor offboarding often breaks down: removing someone's access to a system doesn't necessarily invalidate the credentials they already obtained.

We recently explored this problem in our Passwork blog post on third-party access risk, following a major data breach in Denmark. Here, we'll focus on the engineering side: how to scope contractor access, detect suspicious activity, and verify that access is actually gone when the work ends.

A two-person vendor, 8.8 million exposed records

In September 2026, an attacker reportedly exploited legitimate access held by a small Danish IT company, Pays ApS, to query Denmark's Central Person Register (CPR).

Approximately 8.8 million records were affected.

According to Cybernews, administrators at the vendor reportedly used the password 123456. The attacker also claimed to have obtained a former employee's leaked password. These details remain reported accounts rather than fully established findings.

The important lesson is what the compromised accounts could do.

The blast radius of a compromised account depends on four things:

• Reach: Which systems, records, and credentials can it access?
• Operations: Can it read, modify, delete, or export data?
• Rate: How many requests or records can it process?
• Accounts: How many active identities provide similar access?

A contractor with read access to one repository presents a different risk from one who can export an entire customer database.

Let's apply that distinction to a typical development workflow.

1. Map access before granting it

Imagine an external developer working on a payment integration.

They need one repository, a staging environment, and a test API. They don't need production database access or organization-wide administrator permissions.

Start with a simple access record answering three important questions: who owns this access, what can the contractor do, and where must permissions be revoked?

Keep human accounts, machine tokens, and shared credentials separate. They have different revocation mechanisms.

2. Apply six controls to every contractor account

Control 1: Enforce least privilege

Grant permissions for the task, not the contractor's job title.

In GitHub, restrict repository access. In your cloud IAM, scope permissions to the required resources. For APIs, use narrowly scoped tokens.

Verify: Attempt an operation outside the approved scope using a dedicated test identity. It should fail.

Control 2: Make access temporary

Set an expiration date when granting access.

Use native expiration or just-in-time access where supported. Otherwise, create a tracked revocation task with an accountable owner.

Verify: Check that expired access is actually rejected, not merely marked as expired in a spreadsheet.

Control 3: Use individual identities and credentials

Avoid shared contractor logins.

Give each person an attributable account. Generate strong, unique passwords and use separate API credentials for separate integrations.

Verify: Every active identity maps to a person or documented workload. No two contractors depend on the same personal login.

Control 4: Enforce MFA at your boundary

A contractor's internal security policies may be outside your control. Your own systems shouldn't be.

Require MFA for contractor access to your identity provider, VPN, gateway, or credential vault.

Verify: A password alone cannot authenticate to the protected entry point.

Control 5: Monitor what contractors actually do

Authentication logs tell you who signed in. They don't necessarily tell you what data was accessed afterward.

Collect activity logs from the systems that matter: GitHub, cloud infrastructure, applications, and APIs.

Verify: You can identify the account responsible for sensitive operations and detect unusual activity.

Control 6: Treat offboarding as a security operation

Disabling an account is only the beginning.

Revoke active sessions and tokens, remove permissions, and rotate credentials the contractor could access.

Verify: Previously issued credentials no longer work, and the contractor cannot authenticate through another remaining integration.

3. Test whether your monitoring catches enumeration

The reported unauthorized access in Denmark lasted 21 days and 17 hours before the register's administrators became aware of the breach.

Would your monitoring detect a contractor account systematically querying records?

Look for these signals:

Signal	What to investigate
Request volume	Sudden increase in API calls or database reads
Enumeration	Sequential identifiers or repeated unsuccessful lookups
Unusual access	New locations or activity outside expected working hours
Data extraction	Bulk exports or unusually large responses

You don't need to simulate an actual attack.

In a controlled staging environment, generate a small, authorized sequence of test requests with a dedicated contractor identity.

Then check:

1. Are the requests visible in your application or API logs?
2. Can you attribute them to the correct identity?
3. Does your detection rule fire?
4. How long does it take for the alert to reach someone responsible?

Tune thresholds against normal application behavior. A fixed request count that works for one API may produce constant false positives for another.

4. Revocation and rotation are different operations

Suppose the contractor accessed a shared database password through a credential vault.

You remove their vault permissions.

They can no longer retrieve the password from the vault, but a previously copied value may still authenticate directly to the database.

The same applies to API keys, SSH keys, and other reusable credentials.

A complete offboarding process must address both identity access and credential validity.

This is where credential management tools help. At Passwork, we provide vault- and folder-level permissions, role-based access controls, MFA, and activity logs to help teams manage who can access stored credentials.

But a credential vault has a clear boundary: revoking vault access doesn't automatically revoke external application accounts or invalidate previously copied secrets. Those actions must happen in the target systems.

5. Run this offboarding checklist

Pick one contractor whose project has recently ended.

[ ] Identify the internal owner of the contractor's access.
[ ] List all accounts, permissions, tokens, and accessible secrets.
[ ] Disable or remove the contractor's accounts.
[ ] Revoke active sessions, personal access tokens, and SSH keys.
[ ] Rotate shared credentials and API keys they could retrieve.
[ ] Review relevant application and infrastructure logs.
[ ] Test that old credentials and permissions no longer work.
[ ] Record completion and obtain the owner's sign-off.

One access record, six controls, and a verified offboarding procedure are enough to expose the most obvious gaps.

The question is whether you can identify and invalidate everything contractor's account could access.

What is harder in your stack: revoking contractor accounts or finding every credential they could access?