Supply chain security: the attack vector your organization is probably not controlling properly

When analyzing the most significant cyberattacks of the last decade, a pattern emerges that deserves attention: in most cases, the attacker did not directly access the final target. They entered through someone the target trusted.

SolarWinds. Kaseya. Target. MOVEit. 3CX. In all of these incidents, the entry vector was a supplier. And in all of them, the affected organizations had security policies, third-party assessment processes and, in many cases, valid certifications.

This does not mean those controls are useless. It means that protecting the supply chain requires something more than documenting risk: it requires managing it operationally and continuously. There is a real distance between those two things, and this article is exactly about that.

What supply chain security is (and what it is not)

Supply chain security groups together all the controls, processes and technologies intended to protect an organization’s systems, data and operations against risks that arrive through third parties with access to its environment.

That third party can be any of these profiles, all of them common:

• A software supplier that distributes automatic updates in its clients’ environments.
• A technology integrator with access to the internal network to implement or maintain systems.
• An MSP (managed services provider) that remotely administers critical infrastructure.
• A maintenance company with remote access to industrial facilities, OT or climate control systems.
• A business partner with direct API integration to business systems or sensitive data.

The critical difference compared to internal security is only one: control. When risk comes from inside, the organization has tools to detect it, contain it and respond. When it comes from a third party, that visibility in most organizations simply does not exist.

What supply chain security is not: it is not just checking whether the supplier has ISO 27001. It is not just sending a questionnaire once a year. And it is not just signing a contract with security clauses. We will come back to this.

The attacks that turn theory into urgency

SolarWinds (2020): the attack that redefined what it means to trust a supplier

In December 2020, it was discovered that SolarWinds Orion software, a network monitoring platform used by more than 18,000 organizations, including nine United States federal agencies, had been compromised months earlier. The attackers inserted malicious code directly into the software build process, so legitimate updates distributed the payload to all customers automatically and without any warning sign.

The entry vector was not a technical vulnerability exploited in production. It was the software construction and distribution process of a supplier in which thousands of organizations placed their trust. The victims received the attack through an update they had objective reasons to install.

Kaseya (2021): 1,500 companies compromised in less than two hours

REvil group exploited a zero-day vulnerability in Kaseya VSA, a remote administration tool used by hundreds of MSPs. The attack did not target the end customers: it targeted the suppliers managing their infrastructure. Result was the automated distribution of ransomware to between 800 and 1,500 organizations worldwide in a matter of hours.

The lesson is mathematical: instead of compromising 1,500 targets separately, the attacker compromised one point in the distribution chain and let the system do the rest. The return on investment of that attack, in terms of impact versus effort, is difficult to surpass.

Target (2013): 40 million cards compromised through an HVAC supplier

The Target case remains one of the most cited because it illustrates something many organizations prefer not to see: the entry vector was a facility maintenance services supplier. The attackers obtained its credentials, accessed Target’s corporate network through that insufficiently segmented access, moved laterally to the point-of-sale systems and installed malware that captured data from 40 million cards for weeks.

It was not a technically sophisticated attack. It was third-party access without the appropriate controls, exploited with patience and method.

MOVEit (2023): the attack victims did not even know could reach them

In 2023, the Cl0p group exploited a zero-day vulnerability in MOVEit Transfer, file transfer software used by thousands of organizations. The result was the extraction of data from more than 2,500 entities worldwide. Many of the victims did not use MOVEit directly: their business process outsourcing providers used it, and the affected data belonged to them.

This last nuance is important: in the modern supply chain, risk is not limited to direct suppliers. It extends to suppliers of suppliers. The real attack surface is larger than any conventional inventory captures.

The structural failure: the implicit trust model

Analyzing these cases in isolation leads to incorrect conclusions: “we need better questionnaires,” “we must require more certifications,” “audits need to be more frequent.” The industry has spent a decade repeating these responses. And supply chain attacks continue to grow.

The problem is not the lack of controls. It is that the controls being implemented measure the appearance of security, not real security.

A vendor risk assessment questionnaire measures an organization’s ability to answer questionnaires. An ISO 27001 certification guarantees that a documented and audited management system exists. Neither of the two guarantees that, at this moment, an attacker does not have active access to the client’s systems through the credentials of that certified supplier.

Why does this model persist? Because the incentives of all actors point in the same wrong direction.

The supplier wants certification as a market access requirement, not as a genuine commitment to security. It obtains it, renews it annually with minimum effort and continues operating the same way.

The client company wants to reduce its regulatory and legal exposure, not necessarily its real risk. If it can demonstrate that it performed the assessment process and that the supplier had a valid certification, its liability is significantly limited in the event of an incident.

The regulator designs auditable standards, not necessarily effective ones. What cannot be measured in a form does not exist in a regulatory framework.

The result is an ecosystem perfectly optimized to document risk, not eliminate it.

The vectors most underestimated in practice

Persistent access without active review

The most frequent pattern: an access account is created for a supplier, the privileges required for the project are granted, the project ends. The access remains active. Nobody revokes it because nobody has a systematic process to do so.

In organizations with dozens or hundreds of active suppliers, the inventory of active external accesses rarely matches reality. There are accesses from completed projects, from suppliers that have changed personnel, from integrations that are no longer used. Each of those accesses is an open door nobody is watching.

Lateral movement from poorly segmented VPN access

When a supplier accesses through a traditional corporate VPN, it obtains connectivity to a network segment that, in many cases, is broader than strictly necessary. If that access is compromised, the attacker does not only access the system the supplier was authorized for: it accesses everything that network segment can reach.

Lateral movement from poorly segmented third-party access is one of the most frequent vectors in incidents against critical infrastructure. Not because it is difficult to prevent, but because granular segmentation of external access is rarely implemented with the same rigor applied to the internal network.

Uninventoried software dependencies

Between 80 and 90% of any modern application is composed of third-party code: open-source libraries, commercial components, SDKs, frameworks, external service APIs. Organizations rarely have a complete and updated inventory of these dependencies, known as an SBOM, Software Bill of Materials, and even less an automated process to detect when one of them introduces a known vulnerability.

Log4Shell in 2021 demonstrated the real impact of this problem: a critical vulnerability in a Java logging library affected hundreds of thousands of systems worldwide, many of whose administrators did not even know the library was present in their stack.

API tokens with excessive privileges and no rotation

API integrations between organizations create direct communication channels between systems that in many cases operate with long-duration authentication tokens, without rotation, without anomaly monitoring in usage patterns and with broader permissions than necessary for the function they perform. A compromised token can provide continuous access for months without triggering any alert.

What truly controlling third-party access means

The required change is not technical in origin. It is conceptual: moving from trusting that the supplier is secure to verifying that the supplier acts securely. From documentary control to operational control.

In practice, this is articulated through four principles that must be non-negotiable:

Principle 1: No permanent access — Just-in-Time as the standard

A third party’s access must exist only during the time it is necessary for a specific task. It is requested, approved with the specific privileges that task requires, granted with automatic expiration and revoked at completion without manual intervention.

There are no persistent credentials. There are no permanently open channels. Every access session is a controlled event, not an indefinite state.

This principle alone eliminates a very significant fraction of the attack surface: all active accesses that are no longer necessary.

Principle 2: Intermediated access — the real system is never directly exposed

Instead of granting the supplier direct access to the destination system, the connection is established through a controlled environment acting as an intermediary point. The supplier works within that environment; the production system remains isolated from the external connection.

If the supplier’s device is compromised, the attacker accesses the intermediary environment. The real system remains protected by that isolation layer.

Principle 3: Microsegmentation — access to A does not imply visibility over B

Each supplier’s access must be strictly limited to the system, data and operations required for its specific function, without connectivity to the rest of the infrastructure. Microsegmentation guarantees that a compromised access cannot become the starting point for lateral movement toward critical systems.

Principle 4: Complete session recording — traceability that goes beyond the event log

An event log records what happened: user X accessed system Y at 14:32. A session recording shows how it happened: executed commands, accessed files, transferred data, every action performed and in what order.

Recording third-party access sessions with playback, search and analysis capabilities transforms traceability into a real operational tool: it allows anomalous behaviors to be detected in real time, incidents to be investigated with forensic precision and regulators to be shown the effective level of control over external access.

What this looks like in practice: a real scenario

A technician from an external supplier needs to access a SCADA system in an industrial plant to update controller firmware.

Typical model with VPN: The technician uses credentials not used for weeks. They obtain connectivity to a network segment that includes more systems than needed. They do the work. Nobody monitors the session in detail. The access remains active when the workday ends, and the next day, and the following week.

Operational control model: The technician requests access for that specific task. A representative of the organization approves it for one specific system, with a defined time window. Access is granted through an intermediary environment that only allows visibility of that system. The session is fully recorded. If the technician executes a command outside the expected pattern for that task, an alert is generated. When the time window closes, the access is automatically revoked.

The difference in risk exposure between both models is not marginal. In an environment where an incident in an OT system can have operational or physical consequences, that difference can be critical.

The regulatory framework: NIS2 and DORA are no longer optional

The main cybersecurity regulations currently in force in Europe have incorporated supply chain security as an explicit requirement with real legal and economic consequences.

NIS2 requires organizations in essential and important sectors to implement active measures to manage supplier risk: assess their security posture before establishing relationships, verify their practices and control the accesses granted to them. The sanctioning regime reaches 10 million euros or 2% of annual global turnover.

DORA, in force since January 2025 for the financial sector, imposes specific obligations regarding the management of critical technology supplier risk: dependency inventories, concentration risk assessment, access traceability and documented contingency plans. The level of requirements for ICT service providers considered critical is substantially higher than any previous framework.

ENS (National Security Framework), in its 2022 update, establishes concrete controls over supplier management within the Spanish Public Administration, with specific emphasis on external access control and traceability in medium- and high-category systems.

The most relevant novelty is not only that these regulations require more controls. It is that they require those controls to be verifiable and demonstrable. The annual questionnaire without real monitoring will not meet NIS2 supervision requirements when inspection time arrives.

Conclusion: the weakest link is you if you do not control your chain

Attackers have reached a conclusion the industry is slow to accept: it is more efficient to compromise a supplier with weak controls than to attack a well-protected organization directly. The result is the same, access to the real target’s systems, but the path is exponentially easier.

While organizations invest in protecting their internal perimeter, attackers go around it. And they go around it precisely where control is weakest: third-party access.

The solution does not require replacing the entire security architecture. It requires applying three principles where there is currently a control gap: no persistent access, no access without full traceability, no access without granular segmentation.

Protecting the supply chain is not about protecting suppliers. It is about protecting the business itself against the attack vector that has grown the most in the last decade, and that will grow the most in the next.

---

Do you want to see how Cosmikal implements third-party access control with full traceability, without traditional VPNs and facilitating compliance with NIS2 and DORA?

Request a demonstration.

---

Frequently asked questions about supply chain security

What is a supply chain attack? A supply chain attack is one in which the attacker does not directly compromise the final target, but rather a supplier, partner or software component with access or integration into the target’s systems. The compromised supplier acts as the entry vector toward the real victim.

What are the most relevant examples of supply chain attacks? The most significant cases are SolarWinds (2020), where malicious code was distributed through legitimate software updates; Kaseya (2021), where ransomware affected 1,500 companies through their managed service provider; and MOVEit (2023), which affected more than 2,500 organizations through a vulnerability in file transfer software.

Which European regulations govern third-party security? The main ones are NIS2, which applies to essential and important sectors; DORA, specific to the financial sector and its technology suppliers; and the National Security Framework (ENS) within the Spanish Public Administration. All three require active controls over third-party access and demonstrable traceability.

What is Just-in-Time access for suppliers and why is it important? Just-in-Time (JIT) access is a model in which privileges are granted only when needed for a specific task and are automatically revoked upon completion, leaving no persistent access. It eliminates one of the main supply chain risk vectors: active accesses that no longer have operational justification.

Why is a VPN not enough to control third-party access? A VPN provides encryption for the communication channel, but it does not control what the supplier does once connected, does not limit visibility to specific systems, does not record activity with session-level granularity and does not automatically revoke access. It is a transport measure, not an access control mechanism.

What is an SBOM and why is it relevant in supply chain security? An SBOM (Software Bill of Materials) is a complete inventory of all third-party software components present in an application or system. It allows organizations to identify which external dependencies are in use and detect when one of them introduces a known vulnerability, something critical for managing software supply chain risk.

Related content

• What Zero Trust is and how to apply it to third-party access
• NIS2: what it really requires regarding supplier management
• External privileged access control: PAM for third parties