The most dangerous assumption in cybersecurity is that your security ends at your firewall.
On 15 July 2026, a report about India’s Kudankulam Nuclear Power Plant created a wave of concern across the cybersecurity and critical infrastructure community.
A ransomware group reportedly published a large cache of files on the dark web that were allegedly linked to Reliance Group and related to infrastructure work at Kudankulam’s Units 3 and 4. According to reporting, the data was associated with a server hosted by Yotta, a third-party data centre provider. Reliance acknowledged a partial breach of its data and said the government had been informed. The reported files included purported blueprints, supplier details, inspection records and other project-related documents. The authenticity of the documents and the full extent of the exposure remain under investigation.
Let us be precise about something.
This is not a story about an attacker remotely taking control of a nuclear reactor.
And that distinction matters.
The Indian government had previously stated, in relation to the 2019 KKNPP malware incident, that the infection was limited to the administrative network and that the plant’s control and instrumentation systems were isolated from external and administrative networks.
But here is the uncomfortable lesson:
An organisation does not need to lose control of its most critical system for a cyber incident to become strategically dangerous.
Sometimes, the breach happens somewhere else.
With someone else.
On infrastructure you do not directly operate.
And yet the information exposed may still be connected to your most sensitive assets.
That is the real third-party risk lesson emerging from the Kudankulam case.
The breach did not have to start inside the nuclear plant
When people hear “critical infrastructure cybersecurity,” they usually imagine the obvious attack scenario.
An attacker finds a vulnerability in a plant network.
They bypass a firewall.
They gain access to an OT environment.
They compromise an industrial control system.
The story is easy to understand because the attack follows the traditional perimeter model.
But modern attacks do not always work that way.
The Kudankulam case, as currently reported, presents a different and much more uncomfortable model.
The reported chain looks something like this:
Critical infrastructure project → contractor → third-party data centre → stored project data → ransomware attack → public exposure
The attacker may not need to breach the nuclear facility directly.
They may not need access to a reactor control system.
They may not even need to understand the entire plant architecture.
They may only need to find a connected organisation holding sensitive information related to the project.
This is the fundamental shift in third-party risk.
Your attack surface is no longer defined by the systems you own.
It is defined by the systems that hold your data, connect to your operations, support your projects, or are trusted by your people.
The data may be “administrative”. The intelligence may not be.
One of the most dangerous words in cybersecurity is administrative.
An administrative system is often mentally categorised as less important than an operational system.
That is understandable.
An office network is not a reactor control system.
A project document is not a PLC.
A supplier database is not a safety system.
But attackers do not always look at data through the same lens as defenders.
A document that looks “administrative” to an organisation may provide an adversary with context.
Supplier information can reveal dependencies.
Inspection records can reveal equipment and maintenance patterns.
Project documents can reveal how different organisations interact.
Engineering documentation can reveal design assumptions or infrastructure relationships.
Insurance documents can expose how an organisation categorises and financially models certain risks.
Individually, each document may appear harmless.
The problem is aggregation.
A threat actor does not necessarily need one magical document.
They may need thousands of small pieces of information that, when combined, create a much clearer picture of the target.
This is why data classification cannot be based only on the question:
“Can this file directly control a critical system?”
The better question is:
“What could an adversary understand if they collected enough of our data?”
The vendor is not “just a vendor” anymore
For years, many organisations have treated third-party risk as a procurement activity.
A vendor is selected.
A questionnaire is sent.
A certificate is requested.
A contract is signed.
The vendor is onboarded.
And the security team moves on to the next problem.
This approach is increasingly inadequate.
NIST describes cybersecurity supply chain risk management as the process of identifying, assessing and mitigating risks across the interconnected ICT and OT supply chain throughout the lifecycle of systems and services. That lifecycle includes design, development, deployment, maintenance and even destruction.
That is a very different way of thinking about vendors.
A vendor is not simply a company that provides a service.
A vendor is a security dependency.
And every security dependency creates a question:
What happens to our risk when our data, access or operations move into their environment?
In the Kudankulam case, the reported involvement of a third-party data centre provider is precisely what makes the story relevant to almost every modern organisation.
Because most companies today rely on someone else.
Cloud providers.
Managed service providers.
Data centres.
SaaS platforms.
Payroll systems.
IT support vendors.
Consultants.
Engineering contractors.
Software suppliers.
And increasingly, AI platforms.
The perimeter is no longer a wall.
It is an ecosystem.
The “weakest link” analogy is no longer enough
Cybersecurity professionals often say:
“Your security is only as strong as your weakest link.”
It sounds correct.
But it is incomplete.
The problem is that third-party risk is not always about finding the weakest vendor.
It is about understanding where trust has been transferred.
A highly mature organisation may have excellent internal controls.
Strong MFA.
A capable SOC.
Endpoint detection.
Segmentation.
Incident response.
But if a critical supplier has access to sensitive project data and operates with weaker controls, the risk does not disappear simply because the primary organisation is mature.
In fact, attackers may deliberately target the supplier.
NIST has explicitly highlighted that threat actors may target suppliers of more cyber-mature organisations to exploit weaker points in the broader supply ecosystem.
This is why third-party risk is not just a compliance problem.
It is an asymmetric attack problem.
The attacker searches for the easiest path.
The organisation often focuses on protecting the most important asset.
Those are not always the same thing.
The biggest question is not: “Is the vendor certified?”
It is: “What exactly can the vendor expose?”
This is where many vendor risk programmes fail.
They ask:
- Do you have ISO 27001?
- Do you have a SOC 2 report?
- Do you have a cybersecurity policy?
- Do you conduct vulnerability assessments?
- Do you have an incident response plan?
These questions are not useless.
But they are not enough.
Imagine a company with a valid security certification.
Now ask:
What data does it hold for us?
Where is that data actually stored?
Who can access it?
Which subcontractors can access it?
How is the data moved?
How long is it retained?
What happens when the contract ends?
Can we detect abnormal access?
How quickly will the vendor notify us?
Can the vendor prove what happened during an incident?
This is the difference between vendor assurance and vendor visibility.
A questionnaire tells you what the vendor says about itself.
Visibility helps you understand what is actually happening.
And in 2026, organisations need more of the second.
The Kudankulam lesson: segmentation is necessary, but it is not the whole strategy
One important lesson from the Indian government’s 2019 account of the KKNPP malware incident is the role of network isolation.
The government stated that the affected administrative network was separate from the plant’s control and instrumentation systems, and that the malware did not reach the plant controls. Additional security measures were also taken, including hardening connectivity, restricting removable media and blocking malicious websites and IPs.
That is a powerful cybersecurity principle:
Compromise does not automatically have to become catastrophe.
Segmentation matters.
Isolation matters.
Defence in depth matters.
But there is another lesson that organisations should not ignore.
Network segmentation protects systems. It does not automatically protect information.
An organisation can successfully isolate its OT environment and still have sensitive engineering, project or supplier data exposed elsewhere.
This means security teams must think in two separate dimensions:
- Can an attacker control the system?
- Can an attacker understand the system?
The first is an operational technology question.
The second is an intelligence and information security question.
Critical infrastructure security requires both.
Why “we don’t have direct access to the critical system” is a dangerous argument
This is a sentence security teams hear all the time:
“The vendor does not have direct access to our production environment.”
That may be true.
But it does not necessarily mean the vendor is low risk.
A vendor may hold:
- Architectural information
- Project plans
- Equipment details
- Maintenance records
- Supplier relationships
- Identity information
- Configuration information
- Historical records
The vendor may not be able to log into your system.
But they may possess information that makes your environment easier to understand.
This is where the traditional concept of access needs to evolve.
Access is not only the ability to log in.
Information can also create access advantages.
An attacker who understands how an organisation works is in a better position than an attacker starting with no context.
That is why third-party risk assessments must consider information sensitivity, not just technical privileges.
What should critical infrastructure organisations do differently?
The answer is not to stop using vendors.
That is unrealistic.
Modern infrastructure depends on specialised partners.
The answer is to manage third-party risk as an ongoing security function.
1.Create a real vendor risk tiering model
Not every vendor deserves the same level of scrutiny.
A catering vendor is not the same as a data centre provider.
A marketing agency is not the same as an engineering contractor.
Risk tiering should consider:
- Data sensitivity
- Operational dependency
- Network connectivity
- Privileged access
- Subcontractor involvement
- Geographic and jurisdictional exposure
The more critical the dependency, the deeper the assessment should be.
2. Map data flows, not just vendor names
Most organisations know who their vendors are.
Fewer know exactly where their sensitive data moves after it leaves the organisation.
The real question is:
“If we start with one critical dataset, how many organisations can touch it before it reaches its final destination?”
That exercise can reveal fourth-party risk, hidden service providers and unexpected data locations.
3. Stop treating annual questionnaires as continuous assurance
A vendor can be secure in January and compromised in June.
The risk environment changes.
Personnel change.
Infrastructure changes.
Subcontractors change.
Threat actors change.
NIST’s supply-chain guidance emphasises managing risk across the lifecycle rather than treating it as a one-time procurement exercise.
This is the point where continuous monitoring becomes important.
Organisations should look for indicators such as:
- New exposed services
- Security incidents
- Major ownership changes
- Critical vulnerabilities
- Unexpected infrastructure changes
- Changes in security leadership
- Dark web or threat intelligence signals
A vendor assessment should not become a document that is forgotten after onboarding.
4. Make incident notification contracts specific
“Notify us promptly” is not a security strategy.
Contracts should clearly define:
- What qualifies as a security incident
- Notification timelines
- Escalation contacts
- Evidence preservation requirements
- Investigation cooperation
- Forensic support
- Data recovery expectations
During a breach, ambiguity creates delay.
And delay creates more risk.
5. Understand the vendor’s vendors
A third-party risk programme that stops at the first vendor is often incomplete.
Your vendor may use:
- A cloud provider
- A data centre
- A managed security service
- A backup provider
- A subcontractor
- This creates a chain of dependency.
The question is not simply:
“Is our vendor secure?”
It is:
“What security ecosystem are we trusting?”
The uncomfortable truth: trust is not a security control
Organisations often trust vendors because they have worked together for years.
That is understandable.
Relationships matter.
But in cybersecurity, trust must be supported by evidence.
A long-standing vendor can still suffer a breach.
A large company can still have a security incident.
A certified organisation can still be compromised.
A trusted partner can still become the route through which sensitive information leaves your ecosystem.
The Kudankulam case is a reminder that trust can be transferred faster than visibility.
An organisation may believe it is protecting its critical infrastructure.
But if it does not know where sensitive information is stored, who can access it, and how the third-party ecosystem is monitored, it may only be protecting the part of the environment it can see.
The real lesson from Kudankulam
The most important lesson is not that nuclear facilities are vulnerable.
The current reporting does not establish that the plant’s reactor control systems were compromised.
The deeper lesson is more relevant to every organisation—from critical infrastructure to financial services to technology companies.
Cybersecurity responsibility does not end when data leaves your network.
It follows the data.
It follows the dependency.
It follows the vendor.
And sometimes, it follows the vendor’s vendor.
The next major breach may not begin with an attacker breaking through your firewall.
It may begin with a supplier, a data centre, a cloud account or a forgotten service that your organisation stopped actively monitoring months ago.
The question every security leader should be asking is not:
“Are our systems secure?”
It is:
“Who else can affect our security—and how much do we actually know about them?”
Because in a connected world, third-party risk is no longer someone else’s cybersecurity problem.
It is part of your attack surface.
And the organisations that understand this early will be the ones better prepared for the next breach.
– Wiseman CyberSec
