PENTESTY · EDITORIAL ANALYSIS · · 4 min read
When an authorized account opens too many doors: the Danish CPR lesson
Beyond passwords, businesses need to verify what an authorized account can query, export and continue accessing after its permissions are revoked.
By Pentesty
What is confirmed and what remains an allegation
On October 5, the Danish ministry confirmed unauthorized access to information on about 8.8 million people registered in CPR through abuse of a company's legitimate access. The total includes categories such as deceased people and emigrants. The company's access was suspended. Cyber Security Brazil reports the alleged “123456” password, without official confirmation of that cause. We do not present it as an investigative conclusion.
Five checks for a third-party integration
- Records and fields: Use two fictional organizations and different roles. Check reading, searching and exporting. Record one authorized response and another that should be denied, without using real personal information. Evidence: account, operation, object and observed response.
- Volume and purpose: Agree on a sample and a safe test limit with the vendor. Observe what happens when the workflow exceeds the agreed condition. Do not perform production volume testing without specific authorization and defined stop conditions. Evidence: threshold, expected behavior and actual result.
- Traceability: Run a fictional query and ask operations to locate it. Check whether the record identifies the integration and accountable owner without unnecessarily storing the information retrieved. Confirm who can inspect those audit records. Evidence: a traceable event and its audit fields.
- Complete revocation: Remove the test account's access. Check tokens, sessions and already scheduled tasks. A change in an administration panel needs to correspond to an observed denial in each connected service, rather than a change in appearance alone. Evidence: timestamps and results after revocation.
- Response to a deviation: Simulate an unusual-query alert. Establish who investigates, who can suspend the integration and how that decision reaches teams depending on the service. Record what would be needed to restore authorized operation. Evidence: accountable owners and the decision sequence.
Useful detection needs an available decision
An alert helps only when someone can verify the hypothesis and act. Connect each indicator to business context and an authorized way to stop the activity. Our cloud configuration article examines the relationship between identities and exposure. The financial data security analysis adds context about external dependencies. The exercises above are our recommendations, not a technical reconstruction of the CPR incident.
Frequently asked questions
Was the password 123456 confirmed as the cause?
Not in the primary material reviewed. It appears as an allegation in news coverage. Reviewing controls does not require turning that allegation into an established fact.
Does multifactor authentication solve the entire problem?
It can strengthen authentication, depending on implementation. Authorization, sessions, token scope and the behavior of an account that has already authenticated still need assessment.
Is a fixed query limit enough?
The limit needs to suit the purpose and legitimate workflows. Test enforcement and exceptions, and check whether operations can investigate deviations when they occur.
Should the vendor participate in testing?
Yes, when its systems or boundaries are involved. Agree on authorization, fictional accounts, stop conditions and expected evidence before execution, with accountable people on both sides.
Sources and references
Original Pentesty analysis, published October 15, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.