Third-party access risk: What Denmark's breach got wrong

Third-party access risk is the exposure you carry when vendors, contractors or integration partners hold credentials to your systems or data. Denmark disclosed its scale in October 2026: an attacker used a two-person IT company's legitimate access to the national population register and exposed data on about 8.8 million people.

The reported root cause is ordinary. At least three accounts at the vendor, Pays ApS, are linked to the breach, its admins reportedly used the password "123456", and the access ran for 21 days and 17 hours before the register's administrators learned of it.

Key takeaways

The breach came in through a vendor's accounts. About 8.8 million of the register's 11 million entries were affected.
Vendor headcount did not limit the damage. Reach, query rate and the number of logins set the blast radius.
Six controls form the vendor access blast-radius check: scoped access, time limits, unique generated credentials, MFA at the boundary you control, session monitoring and an offboarding gate at contract end.
The benchmark to beat is 21 days and 17 hours. Test whether your own monitoring would flag anomalous vendor-account activity faster.

What happened in Denmark, and why it is a vendor access story

In September 2026, an attacker used the legitimate register access of Pays ApS, a Danish IT company with two employees, to query Denmark's Central Person Register (CPR). About 8.8 million of its 11 million entries were affected. The entry point was a vendor's accounts, not the register's own systems.

Cybernews reported that at least three accounts at Pays ApS are linked to the breach and that the company's admins reportedly used "123456" as their password. The company's managing director told broadcaster TV 2 that its "legal access to search for information in the CPR system has been abused." Denmark's Central Business Register listed the company with two employees as of July 2026.

An anonymous attacker told the Danish newspaper Politiken that the intrusion began with a leaked password belonging to a former employee of a small Danish company, and that two programs then pulled data out of the register. The Danish Data Protection Agency said the attack involved some form of brute-forcing to enumerate valid CPR numbers, according to BleepingComputer.

Date (2026)	Event	Reported by
September 10	Access begins; it lasts 21 days and 17 hours in total	Cybernews
October 2	CPR administration becomes aware of the breach	BleepingComputer
October 5	Authorities announce the breach, block the company's access and open a police investigation	BleepingComputer

Read as cause and effect: a weak or leaked vendor password gave an attacker the vendor's access, that access allowed three weeks of enumeration, and the enumeration returned records on 8.8 million people.

A CPR number alone does not let someone impersonate a citizen, because Denmark's MitID second factor still stands in the way. Cybernews notes the data can sharpen phishing and be cross-referenced with earlier breaches.

Why does vendor size not shrink the blast radius

Vendor headcount has no effect on how much damage its credentials can do. Blast radius is set by what an account can reach, how much it can pull per hour and how many logins exist. A two-person company with search access to an 11-million-entry register carries the same exposure as a large one.

Cybernews explains why a company that size held that access: organizations can receive authorized access to certain register data to verify customers' addresses or maintain membership records. The consequence, in its words, is that "the security of the register depends, in part, on the security practices of the organizations permitted to query it."

Most companies have the same structure inside their own stack: a payments provider with API keys to customer records, a managed service provider with domain admin rights, an agency with production CMS access. Size each one against four inputs before granting anything.

Input	Question to ask
Reach	How many records, systems or credentials can this account touch?
Operation	Can it read one record, query in bulk, or write?
Rate	Is there a per-account limit and an alert when volume spikes?
Logins	How many accounts exist, and does each belong to one named person?

"We are too small for a vendor access program" is the objection this case answers. Program size should follow the vendor's reach into your data, not your headcount or theirs. What vendor size does change is how much security practice you can assume: a two-person company rarely has a dedicated security function, so verification falls to you.

How fast is third-party access risk growing

Verizon's 2026 Data Breach Investigations Report found third parties involved in 48% of breaches, up from 30% a year earlier, a 60% jump. That earlier figure had itself doubled from the 2024 edition. Denmark is one instance of a pattern that now touches nearly half of the 22,000-plus breaches the report analyzed.

Verizon splits third-party exposure into three archetypes: a vendor in your software supply chain, a vendor hosting your data, and a vendor connected into your environment. Pays ApS belongs to the third group. The same report shows how slowly vendors close the gaps behind the headline.

Finding in Verizon's 2026 report	Figure
Breaches involving a third party	48% (30% in the prior edition)
Third-party organizations that fully fix missing or misconfigured MFA on cloud accounts	23%
Median time to resolve half of weak-password and excessive-permission findings	Nearly 8 months
Organizations with at least one IaaS admin account that has MFA disabled	37%

Half of the weak-password and excessive-permission findings are still open after nearly eight months. The Denmark access lasted three weeks.

The bill keeps rising too. IBM's Cost of a Data Breach Report 2026 puts the global average at $4.99 million per breach, a record and a 12% increase.

Why is requiring MFA not enough for vendor accounts

MFA protects the login surfaces you control. Vendor accounts often sit outside your SSO, outside your MFA enforcement and outside your HR-driven offboarding, so a strong policy on your side says little about the password on theirs. For vendor access, verify account hygiene at the boundary instead of assuming it.

Neither Cybernews nor BleepingComputer mentions a second factor on the compromised accounts. The reported failures sit a layer below MFA: a trivial password on admin accounts, and a former employee's leaked password that, per the attacker, opened the way in.

Once a credential leaks, revocation is slow. GitGuardian's State of Secrets Sprawl 2026 tracked valid secrets found in public GitHub commits in 2022 and found 64% still unrevoked in 2026. A leaked vendor credential stays live until someone owns revoking it.

"Our vendors are certified" does not close the gap. A certificate describes a vendor's program. It cannot tell you whether the account a contractor opens today uses a unique, generated password or a login shared across the company. Shared logins also make the audit trail unreadable: the log shows the company, not the person.

If vendor logins live in spreadsheets and chat threads today, move them into a vault where every credential is generated, scoped and logged. Start a free trial of Passwork and test it with one vendor first.

The vendor access blast-radius check: Six controls for third-party access

The vendor access blast-radius check is a six-control routine for sizing and limiting what a vendor's credentials can reach: scope to the task, time-box the access, issue unique credentials, enforce MFA at your boundary, monitor vendor sessions, and gate offboarding at contract end. Run it before granting access and at every review.

The EU's NIS2 Directive covers this layer. NIS2 Directive (EU) 2022/2555, Article 21(2)(d), lists supply chain security among the risk-management measures that essential and important entities address, including security-related aspects of the relationship with each direct supplier or service provider.

Scope access to the task. Apply least privilege per vendor: grant the specific vaults, systems or API scopes the contract needs, size them with the four inputs above, and keep admin and routine accounts separate. Role-based access makes this repeatable, and the RBAC guide shows how to tie scope to job function. In Denmark, one set of credentials could enumerate millions of entries.
Make access time-bound. Tie every vendor account to the contract or project end date, remove standing access when work pauses, and re-approve at each milestone through a scheduled access review. A leaked password only works while the account does. If the Danish leak came from a former employee, offboarding was the control that would have killed it.
Issue unique, individually attributable credentials. One account per person, never one per company. Generate passwords instead of letting people choose them, and reject known-bad values such as "123456" at creation. Inventory vendor-held credentials first; the SaaS credential management guide shows how.
Enforce MFA at the boundary you control. Put the second factor on your gateway, portal or vault login, whatever the vendor's own posture. A guessed or leaked password then opens nothing by itself. Vendor accounts inside your systems follow the same rule as employee accounts.
Monitor vendor sessions like privileged employee sessions. Log every session, alert on volume spikes, off-hours access and sequential lookups, and review vendor activity on a fixed schedule. Privileged access management covers session recording and just-in-time elevation. The next section gives a benchmark for how fast those alerts need to fire.
Make vendor offboarding a hard gate at contract end. The contract does not close until vendor accounts are disabled, shared credentials are rotated and a final access review is signed. Disabling an account is not the same as rotating what it knew, because passwords, API keys and tokens the vendor already saw stay valid until changed. The employee offboarding guide applies the same logic to staff, and it transfers directly to contractors.

How fast would you catch anomalous vendor access

In the Denmark case the reported access lasted 21 days and 17 hours before the register's administration became aware of the breach on October 2. Use that window as a benchmark: if a vendor account started enumerating records in your systems tomorrow, would your monitoring flag it sooner?

The reported pattern gives you signals to test. A brute-force enumeration produces a high volume of lookups from one account, many of them for identifiers that do not exist, and the attacker also moved data out to storage outside the register.

Signal	In the Denmark pattern	Alert to test
Volume	Lookups continuing for three weeks	Daily query count per vendor account against its baseline
Enumeration	Brute-forcing valid CPR numbers	High rate of failed or sequential lookups from one account
Timing and origin	Not reported	Logins outside contracted hours or from new locations
Exfiltration	Data stored outside the register	Bulk reads or exports by a vendor account

Standing access makes these alerts harder to tune, because an account with no end date has no project boundary to judge its activity against. Time-bound access narrows what you have to watch. Run a tabletop exercise: pick your widest vendor account, simulate the enumeration pattern, and time how long it takes before someone is alerted.

How Passwork helps control vendor and third-party access

Passwork lets a team give each vendor exactly the credentials its contract needs and take them back in one action. Vault-level and folder-level permissions scope access, role-based access control separates administrators from members, and the activity log records who opened what and when. It governs the credentials stored in the vault.

Passwork's access management model maps onto the six controls above.

Control	Passwork capability
1. Scope to the task	Access levels set per vault and folder (Full, Read-only, Forbidden), custom vault types per project or access tier, and policy-assigned corporate administrators that a vault owner cannot remove
2. Time-bound access	Time-limited, optionally one-time external links for credentials a vendor needs once, with no account required; ongoing vendor access ends when the vendor's group is disabled
3. Unique credentials	Per-user accounts and a built-in password generator that enforces organization-defined complexity rules
4. MFA at your boundary	Administrators can enforce two-factor authentication (TOTP, WebAuthn) for every account; SAML SSO and LDAP/AD for staff
5. Monitoring	Activity log of user, admin and system actions, exportable to Syslog or a SIEM
6. Offboarding gate	Disable a vendor's group without deleting it; the security dashboard flags credentials still reachable by users whose access was revoked, which gives the rotation list

Put each vendor's people in one group and tie the group's disable action to the contract end date in your offboarding checklist. That is one step instead of a per-account hunt.

A vault governs credentials you store and issue. It cannot enforce password rules inside a vendor's own systems or a government register, so those controls still depend on contract terms, audit rights and the monitoring in control 5. Revoking access also does not erase what a contractor already saw: rotate anything they opened.

What to do about third-party access risk this quarter

The Denmark register was exposed through a vendor's logins, and the vendor's size changed nothing about the outcome. Treat third-party access risk as a sizing problem first: list what each vendor account can reach, give every person a generated credential of their own, and put an end date and a monitoring alert on each one.

Next step: list every vendor and contractor account with standing access this week, then run the blast-radius check on the three with the widest reach.

If your team grants vendors or contractors access to shared credentials, start a free trial of Passwork and scope that access by vault, share one-off credentials through time-limited links, and revoke a vendor group in one step, with an audit trail behind every action.

Frequently asked questions about third-party access risk

What is third-party access risk?

Third-party access risk is the exposure an organization takes on when vendors, contractors or integration partners hold access to its systems or data. The risk sits outside your own security perimeter but can still expose your data, as in Denmark's 2026 CPR breach, where a vendor's compromised accounts reached 8.8 million records.

How is vendor access different from employee access?

Vendor accounts often sit outside an organization's own MFA, SSO and HR-driven offboarding processes, so they need their own access policy, review cadence and revocation trigger. Tie those to the contract, not the org chart: access starts and ends with the statement of work, and a named owner signs each review.

What is a realistic timeline for reviewing vendor access permissions?

Review privileged vendor accounts quarterly, standard vendor accounts at least twice a year, and every account at contract milestones, scope changes and contract end. Treat the final review as a hard gate for closing the contract. These cadences are a practical baseline; adjust them to your own risk assessment.

Does a password manager alone solve vendor access risk?

No. A password manager controls the credentials stored in it: who holds them, how they are generated, who opened them and when. It cannot enforce password rules inside a vendor's own systems, so contract terms, MFA at your boundary, monitoring and offboarding gates still matter. It is the foundation the other controls build on.

What should happen to vendor access when a contract ends?

Disable every vendor account, rotate each shared credential and API key the vendor could read, review the activity log for the contract period, and record sign-off before closing the contract. Disabling accounts alone leaves passwords and tokens the vendor already saw valid, so rotation is a separate step.