Database query monitoring became the clearest lesson from Denmark's national identity breach on October 6, 2026. Fresh reporting revealed that an unusually large invoice, rather than a real-time security alert, exposed the abuse of a company's lawful access to the Central Person Register, or CPR. Attackers had used automated lookups to reach names, addresses, identity numbers, and other data linked to about 8.8 million registered people.
The case matters far beyond one government registry. If a contractor, application, service account, or partner is allowed to retrieve sensitive records, authentication alone cannot tell you whether each lookup is legitimate. You also need to measure volume, velocity, sequence, source, and business purpose while the queries happen.
Key Takeaway: A valid account can produce invalid behavior. Monitor how approved access is used, not only whether the login succeeded.
What today's CPR breach update revealed
The Local reported on October 6 that a large bill submitted by a small Danish company drew attention to heavy activity associated with its CPR access. A ministry official said the company had legal access, but that access had been abused. The reporting also said the registry lacked an automated alarm for the lookup method used and that the activity might otherwise have remained unnoticed until a later invoicing cycle.
The Danish ministry's initial October 5 disclosure said unauthorized parties used a private company's lawful connection to obtain names, addresses, CPR numbers, and other information. The 8.8 million figure includes living people, people who moved away, and deceased people, so it should not be confused with Denmark's current population.
Denmark's data protection authority separately said the event involved a very large number of automated lookups intended to identify valid CPR numbers. Its investigation was still at an early stage, so attribution, precise entry method, and responsibility were not settled when this article was written.
That uncertainty is important. The public facts support conclusions about detection and access design, but not speculation about which technical weakness or person caused the compromise.
Key Stat: Approximately 8.8 million records were exposed through automated use of an account that was already authorized to query the register.
Why authorized access defeats perimeter-only security
Traditional controls answer a narrow question: is this identity allowed to connect? Once credentials, tokens, or an approved integration are abused, a firewall and an allowlist may see normal traffic from a trusted path.
The database sees a different truth. It can reveal that one customer account suddenly requests far more records than usual, touches identifiers outside its normal business population, runs continuously, or repeats a lookup pattern at machine speed.
This is the gap between authorization and intent. A payroll provider may need to validate a limited set of people. It does not necessarily need unlimited, unthrottled access to a national register. A support integration may need one customer record after a case opens, not thousands of unrelated records overnight.
Hexon's guide to vendor access risk explains how third-party permissions can outlive their original scope. Database query monitoring adds the runtime evidence needed to determine whether a still-valid connection is behaving as expected.
The same principle applies to internal service accounts. A credential may be authentic, the source network approved, and the query syntactically valid while the overall behavior is unmistakably wrong.
Common Mistake: Treating a successful login from an allowlisted integration as proof that subsequent data access is legitimate.
What database query monitoring should capture
A useful monitoring program does not need to store every returned value. It needs enough structured evidence to reconstruct who accessed what, when, from where, at what scale, and through which business workflow.
Capture these fields where the platform permits:
- account, application, tenant, customer, and delegated user identifiers
- source address, device, connector, API client, and authentication method
- query type, target table or data class, and requested operation
- number of records examined, matched, returned, or exported
- timestamp, duration, request rate, and session identifier
- reason code, case number, job identifier, or initiating business event
- success, failure, throttling, and policy-decision results
The strongest telemetry joins database events with identity, application, billing, and network records. A billing spike may show unusual consumption. Query logs can show exactly which account and data classes created it. Identity logs can show a new source or token, while application traces can reveal whether a legitimate user action initiated the request.
Microsoft's database threat-detection guidance describes alerting on anomalous access and query patterns as a separate layer beyond ordinary access control. The product choice varies, but the control objective is consistent: turn data access into a monitored security event stream.
Retain the records long enough to investigate delayed discoveries. Protect them from the administrators and services they monitor, and restrict access because audit logs can themselves reveal sensitive schema, identities, and business activity.
Build baselines around accounts and business purpose
A flat threshold such as 10,000 queries per hour is easy to deploy and easy to evade. It also creates noise when one batch-processing account routinely handles millions of records while another should retrieve only five.
Start with a behavioral baseline for each account or account class:
- What data can it normally reach?
- How many records does it request per hour and per day?
- Which source systems, networks, and regions are expected?
- What hours and job schedules are normal?
- Which users, tickets, or business events initiate access?
- How much variation is legitimate during seasonal peaks?
Then define alerts on deviations that have security meaning. Useful signals include a sudden increase in unique identifiers queried, sequential enumeration, repeated misses while probing valid records, access outside contracted populations, a new source, and retrieval continuing after the initiating job ends.
Baselines should use both short and long windows. A burst detector can identify rapid extraction, while a weekly or monthly cumulative limit can expose low-and-slow collection. Peer comparison can also reveal one reseller, contractor, or branch office behaving differently from others with the same role.
Do not let the baseline silently learn an attack as normal. Large changes should require review, and new integrations should begin with conservative limits until their expected behavior is demonstrated.
Pro Tip: Attach a business identifier to every sensitive query. An alert is much easier to investigate when it can be matched to a customer request, employee task, or scheduled job.
Put limits in front of the data, not just alerts behind it
Detection can shorten dwell time, but preventive controls reduce how much data one compromised identity can retrieve. Rate limits, quotas, purpose restrictions, and step-up approval should be designed per account and data sensitivity.
Practical controls include:
- per-minute and per-day limits on lookups and unique records
- separate quotas for interactive use, batch jobs, and bulk exports
- deny rules for sequential or pattern-based enumeration
- restrictions to contracted customer, region, or record populations
- expiring credentials and narrowly scoped service identities
- approval for unusually large jobs or new query shapes
- automatic suspension when high-confidence abuse signals fire
Rate limiting is not only an availability control. It sets an upper bound on extraction speed and creates time for responders to intervene. Limits should fail safely, notify an accountable owner, and support a controlled exception process for legitimate peaks.
Avoid shared credentials because they erase attribution and make containment harder. Hexon's shared account security guide explains why individual identities, strong authentication, and traceable actions matter even when several people perform the same role.
For machine access, assign one service identity per integration or workload. If ten partners share one API key, you cannot reliably baseline them, revoke one connection, or explain which party generated an abusive query stream.
Alert on sequences that reveal data harvesting
Single events are often ambiguous. A large query can be a legitimate report, and a new source can reflect a migration. A sequence can show intent more clearly.
High-value alert chains include:
- new source or token, followed by repeated failed lookups, then a high valid-record rate
- unusual access time, increasing query volume, and broadening data scope
- bulk retrieval immediately after an account permission change
- many identifiers queried with no matching customer or case activity
- a rate-limit warning followed by retries across parallel sessions
- sensitive lookups followed by archive creation or outbound transfer
Score these events together instead of flooding analysts with isolated alerts. Route high-confidence sequences to a team that can suspend the identity, preserve logs, and contact the partner quickly.
The session revocation guide covers a related containment lesson: changing a password may not terminate active tokens. A database-monitoring playbook should identify every session and credential tied to the account so responders can stop ongoing access rather than only prevent the next login.
Alert ownership also matters. Database administrators may understand query shape, application teams know business context, identity teams can revoke access, and the security operations center coordinates the incident. Define those handoffs before an alert fires.
Respond to suspicious high-volume queries
When monitoring identifies likely harvesting, contain access while preserving evidence. Disable or throttle the affected integration, revoke active credentials and sessions, and block unexpected sources. If the service is essential, move it to a restricted mode that permits only verified transactions.
Next, establish scope:
- Identify the first abnormal query and the last confirmed activity.
- Count unique records and sensitive fields accessed, not only total requests.
- Map every credential, token, session, host, and user tied to the integration.
- Determine whether logs are complete and whether monitoring was altered.
- Compare retrieved data with contractual purpose and authorization.
- Preserve application, database, identity, network, and billing evidence.
Notify legal, privacy, customer, regulator, and law-enforcement contacts according to the facts and applicable obligations. Avoid announcing an exact cause until the investigation supports it.
Recovery should address the failed control, not only replace the credential. Reissue narrowly scoped identities, lower initial limits, add live alerts, and test automatic containment. Review similar integrations because the same design weakness may exist across multiple partners.
Hexon's SaaS offboarding checklist is useful for finding connected identities and integrations that should no longer exist. Apply that inventory discipline continuously, not only when a vendor relationship ends.
Key Takeaway: If billing is the first anomaly detector, the organization has cost visibility but not security visibility. Use the same consumption signals in real time and connect them to data-access evidence.
A practical database query monitoring checklist
Use the CPR breach lesson to test your own high-value data systems:
- Inventory every human, service, partner, and batch identity with sensitive read access.
- Give each integration a unique credential and accountable owner.
- Log query source, scope, volume, result count, and business context.
- Baseline normal behavior per account instead of using one global threshold.
- Alert on spikes, enumeration patterns, new sources, and scope expansion.
- Add short-window rate limits and longer cumulative quotas.
- Require approval for bulk jobs and unusual query shapes.
- Connect database, identity, application, network, and billing telemetry.
- Test revocation of credentials, tokens, and active sessions.
- Run an exercise that starts with a trusted account retrieving too much data.
The freshest disclosure from Denmark shows why database security cannot stop at permission checks. Legitimate access became the route to mass retrieval, and an invoice surfaced the anomaly after the activity had already occurred.
Database query monitoring closes that gap by making usage patterns visible while they can still be contained. Pair unique identities with per-account baselines, hard extraction limits, sequence-based alerts, and a practiced response path. When a trusted account starts acting like a harvesting tool, your security team should learn from the queries before finance learns from the bill.