The Question at Hand
In September, a private Danish company's credentials were used to access 8.8 million CPR records. The Ministry of Research, Education and Digitalisation confirmed that unauthorized persons exploited legitimate permissions beyond their intended scope. This wasn't a network breach or malware attack but a misuse of granted access.
This incident raises a key question in third-party risk management (TPRM): Should vendors with contractual data access have continuous connectivity, or should you enforce session-based, dynamically scoped permissions tied to real-time risk signals?
The Case for Persistent Vendor Access
Many TPRM teams allow vendors ongoing access because it's simpler and aligns with pre-established trust. If you've conducted pre-contractual assessments, reviewed SOC 2 reports, and negotiated liability clauses, you've laid the groundwork for trust. Requiring vendors to request access for each query can slow down business operations.
Consider vendors handling Critical or Important Functions like payroll processing or regulatory reporting. These roles often require real-time data access. Revoking access between sessions can disrupt workflows and increase support demands. Your procurement and legal teams have negotiated access rights; your task is to monitor for misuse, not re-authenticate every interaction.
This model aligns with most enterprise Identity and Access Management (IAM) systems. You provision roles, enforce multi-factor authentication (MFA), and log activity. If a vendor's account shows irregular behavior, your Security Operations Center (SOC) investigates. The CPR administration detected the breach by noticing "irregular behavior", the system worked, but earlier intervention might have been possible.
From a contract perspective, persistent access simplifies monitoring service level agreements (SLAs). If you're measuring response times or uptime, intermittent access complicates performance evaluations. Vendors argue that session-based models shift operational risk back to you: if they can't access data when needed, they can't meet their obligations.
The Case for Dynamic, Time-Boxed Permissions
On the other hand, persistent vendor access can create an unmonitored attack surface. Even if you've vetted the vendor, you haven't vetted every employee with access to their credentials or every subcontractor in their chain.
SecurityScorecard's Michael Centrella emphasizes that "vendor risk management cannot rely on static, annual reviews" and that security teams must continuously monitor third-party access patterns. This means granting access only when needed, scoped to specific data sets, and revoked after a session ends.
Huntress's Dray Agha points to the CPR breach as proof that "a compromised account at a single supplier can bypass an organization's core security controls." If the vendor had requested access for each query, unauthorized users would have needed to justify each request in real time, creating a chance to detect the breach before data was extracted.
Dynamic permissions align with zero-trust architecture principles. You authenticate the user, validate the device, verify the data scope, and enforce least-privilege access. If a vendor's cyber risk rating drops, due to a new vulnerability or a threat intelligence alert, you can automatically limit or suspend access until they address the issue.
Session-based access also limits the potential damage. If credentials leak, the window of exploitability is hours, not months. You're not just relying on anomaly detection; you're reducing exposure by design.
Where Practitioners Actually Land
Most TPRM teams find a middle ground, tiering vendors by criticality and applying different access models. For low-risk vendors with limited data scope, persistent access with annual reviews is common. For vendors handling sensitive data, you'll see tighter controls: quarterly reviews, automated session timeouts, and dynamic permissions based on risk scores.
The challenge is that "criticality" often reflects business impact, not data sensitivity. A vendor supporting a critical function may access only aggregated data, while a "low criticality" vendor might access raw records, as seen in the CPR breach.
Practitioners also face tooling gaps. Most IAM platforms can enforce session limits, but few integrate real-time risk ratings to adjust permissions dynamically. You can monitor access logs for anomalies, but by the time you detect irregular behavior, data may already be compromised. As Acumen Cyber's Nathan Davies-Webb notes, you need "stronger authentication, shorter sessions, rate limiting data requests, and creating a baseline of normal behavior," but implementing these requires coordination across IAM, SIEM, and TPRM platforms.
Our Take
Persistent vendor access is a choice, not a necessity. If you grant it, you're relying on detection as your main control, and the CPR breach shows that detection alone isn't enough.
We recommend session-based access as the default for vendors handling personal data, financial records, or datasets subject to CSRD reporting requirements. Limit each session to the necessary data, enforce re-authentication every 4-8 hours, and integrate access decisions with continuous monitoring. If a vendor's risk posture worsens, their access should be reduced accordingly.
For vendors supporting Critical or Important Functions where persistent access is necessary, add compensating controls: rate limiting queries, automated alerts for bulk exports, and contractual obligations for vendors to report credential compromises quickly.
The CPR administration detected irregular behavior quickly, but couldn't prevent data extraction. Your goal should be not just faster detection but structural prevention through access architecture that assumes credentials will be compromised and limits what an attacker can do with them.
