Denmark's September breach exposed 8.8 million citizen records through a single compromised company account. Over 10 days, attackers ran more than 14 million searches against the national registry before administrators noticed. This wasn't a sophisticated exploit; it was a credential problem.
Your vendor access controls likely have the same vulnerabilities.
Why These Mistakes Keep Happening
Most teams treat vendor access as a provisioning issue, not a security one. You grant credentials, set a review date six months out, and move on. The account sits there with broad query rights, no activity monitoring, and credentials that never expire.
The pattern repeats because vendor relationships feel stable. You've worked with the payroll provider for three years. The background check firm has a contract. The audit firm needs read access for compliance work. None of these relationships feel like attack vectors until someone uses those credentials to harvest your entire database.
Another reason: access reviews focus on what vendors should see, not what they're actually doing. You verify that the account still needs access. You don't verify that last week's 10,000 queries were legitimate business activity.
Mistake 1: Granting Query Access Without Rate Limits
Why it happens: You provision vendor accounts based on job function. The background screening firm needs to look up employment records, so you give them query access to your HR database. You don't think about volume because their contract covers 50 checks per month.
The consequence: Nothing stops that account from running 500 queries in an hour. In Denmark's case, attackers executed 14 million searches through a single company account. The system had no mechanism to flag or throttle unusual query volumes.
The fix: Implement query rate limits tied to contractual usage. If your vendor processes 200 requests monthly, flag any account that exceeds 250 queries in a 24-hour period. Use your API gateway or database access layer to enforce these limits automatically. When a vendor hits the threshold, suspend the account and require manual approval to restore access.
For high-value databases, add a second control: require vendors to submit batch requests through a controlled interface rather than granting direct query access. You review the batch, validate the volume, and return results. This adds friction, but it eliminates the master-key problem.
Mistake 2: Using Shared Credentials Across Vendor Teams
Why it happens: Your vendor contact requests "system access for our team." You create one service account with a shared password. It's simpler than provisioning individual accounts, and the vendor's internal access controls aren't your responsibility.
The consequence: You can't trace activity to individuals. When the account is compromised, you don't know if it was the vendor's employee, a contractor, or an external attacker. You also can't revoke access granularly when someone leaves the vendor's team.
The fix: Require individual accounts for every person who touches your systems, even vendor staff. Use Security Assertion Markup Language or your identity provider to federate authentication, so the vendor's HR system automatically triggers deprovisioning when someone leaves.
If you must use service accounts for automated integrations, treat them like production secrets: store credentials in a vault, rotate them quarterly, and log every authentication. Never share service account credentials via email or Slack.
Mistake 3: Skipping Multi-Factor Authentication for Non-Employee Accounts
Why it happens: Your internal staff uses multi-factor authentication, but vendor accounts authenticate with passwords alone. The reasoning: vendors access your systems infrequently, and adding MFA creates support burden.
The consequence: Stolen credentials give attackers immediate access. Denmark's authorities are now advising organizations not to rely on CPR numbers alone for identity verification and to implement stronger mechanisms such as MitID or two-factor authentication. That guidance applies equally to how you verify the humans accessing your systems.
The fix: Enforce multi-factor authentication for all external accounts, no exceptions. Use time-based one-time passwords, hardware tokens, or push notifications. For vendors who resist, make MFA a contract requirement.
For highly sensitive systems, implement break-glass access: vendors request temporary credentials that expire after four hours. Each request generates an alert to your security team. This model works particularly well for vendors who need occasional access rather than continuous connectivity.
Mistake 4: Treating Access Reviews as Checkbox Compliance
Why it happens: Your quarterly access review asks: "Does this vendor still need access?" The business owner clicks yes, and the account remains active. No one examines what the account actually did last quarter.
The consequence: Compromised accounts stay active for months. In Denmark's incident, administrators discovered the breach only after noticing unusual activity. By then, attackers had already harvested 8.8 million records. Earlier detection would have required someone to actively monitor query patterns, not just verify that the vendor relationship still existed.
The fix: Build behavioral monitoring into your access reviews. Before asking "should this account remain active," show the reviewer what it did: query volume, data accessed, access times, source IP addresses. Flag anomalies automatically. Did the account suddenly start querying on weekends? Did query volume jump 300% last month? Did access originate from a new geographic region?
For high-risk vendor accounts, implement continuous certification: the business owner receives a weekly summary of account activity and must acknowledge it. If they don't respond within 48 hours, suspend the account.
Mistake 5: Failing to Scope Access to Specific Data Sets
Why it happens: Your vendor needs access to customer records for a specific project. You grant database-level read access because row-level security is complicated. The vendor can now query any customer record, not just the ones relevant to their work.
The consequence: Breach scope expands dramatically. Denmark's incident exposed records for people living in Denmark, deceased individuals, and those who moved abroad. The only records protected were those with restricted addresses already flagged in the system. If the compromised account had been scoped to active residents only, the breach would have affected a fraction of the total.
The fix: Implement column-level security and row-level filters for every vendor account. Use database views that expose only the fields and records the vendor needs. If they're processing employment verifications for your Munich office, they shouldn't see payroll data or access records for your Tokyo employees.
Document the scoping logic in your vendor contract and data processing agreement. When the vendor's scope changes, provision a new account rather than expanding permissions on the existing one. This creates an audit trail and forces you to re-evaluate access boundaries.
Prevention Checklist
Before provisioning your next vendor account, verify:
- Query rate limits are configured based on contractual usage volume
- Individual accounts exist for each vendor team member (no shared credentials)
- Multi-factor authentication is enforced for all external accounts
- Automated alerts flag unusual query patterns, access times, or source locations
- Access reviews include behavioral data, not just relationship status
- Row-level and column-level security restrict access to specific data sets
- Service account credentials are stored in a vault and rotated quarterly
- Break-glass access procedures exist for vendors requiring temporary elevated access
- Deprovisioning triggers automatically when vendor contracts end
- Activity logs are retained and reviewed before each access certification
Denmark's breach happened because a single compromised account had too much access and too little oversight. Your vendor accounts carry the same risk. The difference is whether you discover the problem during a routine access review or after someone harvests your entire database.
