Third-Party Access Can Be Scoped and Still Authorize the Wrong Action

The enterprise control question is more specific than whether a contractor, vendor, MSP, or other outside party should have access to a system.

Veradigm disclosed this week that credentials taken from one of its third-party vendors were used to access a company API and download patient personal data, including Social Security numbers in some cases. The same credentials were limited to that interface and, according to Veradigm, did not provide access to its broader network, servers, databases, or other systems.

That detail deserves more attention than the usual third-party-breach headline. Limiting the vendor credential appears to have contained the reach of the incident. Sensitive information was still available through the path the credential could reach.

The enterprise control question is therefore more specific than whether a contractor, vendor, MSP, or other outside party should have access to a system.

Signals & Moves You Shouldn't Ignore

Veradigm: the compromised vendor credential had a boundary

Veradigm's September 8 SEC filing says an unauthorized party obtained credentials from a third-party vendor's environment for an API the vendor used to provide services on behalf of Veradigm customers. Those credentials were then used to download copies of certain patient personal data. Veradigm said some records included Social Security numbers, while clinical and medical data were not involved.

The filing also establishes an important limitation: the compromised credentials provided access only through the specified interface. Veradigm says they did not provide access to the company's broader network, servers, databases, or other systems, and the incident caused no operational disruption. Its investigation remains ongoing.

That is evidence of containment, not evidence that the sensitive operation available through the API was appropriate for an unauthorized user. The useful enterprise distinction is between the reach of an account and the actions available inside that reach.

Source: Veradigm Inc. Form 8-K, September 8, 2026

ScreenConnect: an active remote session did not guarantee action-level authorization

Also on September 8, ConnectWise released ScreenConnect 26.6.5 to address CVE-2026-84869. ConnectWise classifies the vulnerability as Missing Authorization and Improper Privilege Management with a CVSS base score of 9.9. Versions before 26.6.5 are affected.

ConnectWise says the flaw could, in certain circumstances, allow files to be transferred and executed through an active remote session without authorization or host confirmation. ScreenConnect servers themselves are not affected. ConnectWise recommends updating and provides a temporary mitigation involving removal of the TransferFiles permission where immediate patching is not possible.

The product vulnerability is specific. The control distinction travels much further.

A valid remote-support session establishes that a channel exists between two parties. It does not establish that every consequential operation available through that channel belongs to the purpose for which access was granted.

Source: ConnectWise, ScreenConnect 26.6.5 Security Patch, CVE-2026-84869, September 8, 2026

Microsoft: authentication can persist into a very different set of actions

Microsoft Security Research published details on September 9 about active cloud intrusions it has observed since May. Microsoft says the activity often begins with a phone call or message to an employee's personal number using passkey, MFA, or SSO enrollment as the pretext. Some victims are directed through adversary-in-the-middle or device-code flows that result in compromised credentials, tokens, or user-authorized attacker access.

In one investigated sequence, MFA was completed and the resulting session was subsequently used to enumerate applications, access identity-management interfaces and conduct Microsoft Graph reconnaissance. Microsoft also observed high-volume SharePoint and OneDrive access in the wider campaign. It warns that the initial interaction may leave little endpoint evidence when the victim uses a personal mobile device that is not onboarded to Defender for Endpoint.

Microsoft's report concerns compromised employees, not a contractor incident. It belongs here because it exposes the same evidence problem from another direction: authentication establishes a moment of identity assurance. The actions that follow can move far beyond what the person believed they were approving.

Source: Microsoft Security Research, "Passkey-themed social engineering leads to identity and cloud compromise," September 9, 2026

The Control Gap

Third-party access programs are usually good at nouns.

Vendor. Contractor. MSP. Account. Application. Role. Device. Ticket.

The harder part is the verb.

Download the customer records. Repair this endpoint. Change this configuration. Retrieve these logs. Administer this tenant. Access this dataset for this engagement.

Those are the actions the business actually needs an outside party to perform, and they are where the consequence sits.

An organization can therefore have a properly identified vendor, a legitimate account, a narrowly scoped application, a valid session, and extensive logging while still being unable to produce a simple record answering:

What exactly did we authorize this outside party to do?

That question remains useful after this week's vulnerabilities and incident reports disappear from the news cycle.

My Take

Third-party access reviews tend to spend too much of their precision on admission.

Security asks who the vendor is. IAM determines the role. Procurement establishes the relationship. Legal handles contractual language. IT opens the technical path. Someone eventually needs the work completed, so the account gets approved.

The business purpose behind that account often survives as a sentence in a ticket, an email thread, a statement of work, or somebody's memory.

That leaves a strange evidence gap. Organizations can sometimes prove authentication more precisely than they can prove authorization. They know who signed in, when the session began, which role existed, and which system was reached. Reconstructing the actual conditions the company intended to place around the work can require several teams and several systems.

Third-party access should begin with a bounded business action. Identity, device posture, role, session, system scope, data access, evidence requirements, expiration, and revocation should support that action.

Otherwise the organization is governing an account while assuming the work performed through it will remain inside the original intent.

— William

One Thing Worth Doing This Week

Pick one active third-party relationship with meaningful access and create a dated Third-Party Action Record.

Keep it to one page.

The exercise is complete when one responsible person can read that page and tell what the outside party is allowed to do without reconstructing the answer from IAM, procurement, a ticketing system, and a contract.

The disagreements are the useful output. They identify where access exists without a shared definition of the work it was supposed to authorize.

Field Notes

I spent part of this week looking for mission-aligned organizations where third-party access is an operating problem rather than a hypothetical security concern. Nonprofits have been particularly useful to study because outside partners, contractors, service providers, sensitive populations, limited internal resources, and mission obligations can meet in the same organization. The prospecting work has forced me to start with the work the outside party needs to perform and the evidence an organization should reasonably ask for, rather than starting with a security product.

At the same time, I have been testing the infrastructure around the artifacts I use for that work. Conditions of Approval moved from a browser tool into an installable web application and an iOS build now in TestFlight. The app keeps its criteria and saved records local, can export the resulting record as a PDF, and does not currently make network calls. I also found that a separate statement-of-work gate I had built was not sending the notifications it was supposed to send. The Worker and automation looked connected from the outside. They were not. I fixed the production path and verified successful events reached the workflow, but I still have not verified every rejection path, so I am not treating that work as finished.

Those two pieces of work changed how I am looking at third-party access. A policy saying an organization reviews vendors is easy to write. A login showing that somebody authenticated is easy to retain. Even a workflow that appears connected can turn out to have never produced the evidence you thought it was producing.

The useful standard is more demanding: pick one outside party, define the work they are being allowed to perform, write the conditions around that work, and verify that the evidence you expect to exist actually exists.

That is the standard I am now using in the organizations I approach and in the tools I build for them.

Could you produce, today, a dated Third-Party Action Record for one active outside party with meaningful access, and show the evidence that the access currently enabled matches the action the organization intended to approve?

EVERY FRIDAY. SIGNALS. ONE CONTROL GAP. ONE ACTION.

Sources

• Veradigm Inc. Form 8-K, September 8, 2026
• ConnectWise, ScreenConnect 26.6.5 Security Patch, CVE-2026-84869, September 8, 2026
• Microsoft Security Research, "Passkey-themed social engineering leads to identity and cloud compromise," September 9, 2026

#MobileSecurity #CISO #cybersecurity #ThirdPartyRisk #VendorRiskManagement #IdentitySecurity