At 9 AM on a Tuesday, a vendor’s technician from a core banking software company walked into the server room of a Mumbai NBFC.
The physical security and Admin team expected and approved his visit. The IT head had the work order for him. A routine software patch, scheduled two weeks earlier. The technician had been here before. The vendor had been supporting their core banking system for three years. They trusted the relationship, and this visit was routine.
The technician connected his laptop to the network port in the server room. The IT head showed him to the system, confirmed the job scope, and went back to his desk. Eight hours later, the technician packed up, said goodbye, and left.
What the IT head did not know, and had no mechanism to find out, was the following.
That laptop had visited 11 other financial institutions in the previous six weeks. A cooperative bank in Nashik. Two NBFCs in Pune. An insurance company in Chennai. Several more across Maharashtra and Karnataka. At each site, the technician had connected to their networks, done the job, and left. At each site, the laptop had been on the network for hours.
The laptop was running a browser extension installed from a personal email account that the technician used on the same machine. It had debugging tools from previous engagements that were never uninstalled. Its Windows Defender definitions had not been updated in 47 days. It carried cached credentials from at least two previous client sites.
When it connected to the NBFC’s server room network port, it received an internal IP address and full access to every network segment that port could reach.
No verification. No restriction. No monitoring.
IT head had no way of knowing what the vendor’s technician’s laptop was carrying, where it had been, or what it could reach once it was inside.
This is the most common uncontrolled entry point in Indian enterprise networks. It is not a shadow IT problem. It is not a rogue employee. It is an invited guest. And most Indian companies have never built a control that checks the device rather than the person.
What You Know About the Vendor and His Device
Every Indian bank, NBFC, and manufacturer that uses third-party software, hardware, or technology services eventually has a technician in their building.
The vendor’s technician is not the risk. The vendor’s technician is doing a job that needs to be done. Core banking software needs patches. ERP systems need configuration support. Biometric attendance machines need firmware updates. Fire safety systems need calibration. HVAC control units need software maintenance. All of these are legitimate services performed by legitimate vendors.
The question is not whether to let the vendor in. The question is what happens when their device connects to your network.
Here is what you know about the vendor. You know their company name, having relation with them for many years. You have a contract and an NDA signed with them. You have a proper work order. You have their technician’s employee badge number. You may have done a background verification of the company before onboarding them.
But you know nothing about his device.
You do not know when it was last scanned for malware. You do not know what software is installed on it. You do not know what other corporate networks it has been connected to. You do not know what credentials are cached on it from previous client engagements. You do not know whether someone installed something on it between their last client visit and yours. You do not know if the technician uses it for personal browsing.
When that device connects to your network port, all of that unknown history connects with it.
What Happens on Your Network in Those Eight Hours
Most vendor maintenance visits are exactly what they appear to be. The technician does the job and leaves. No incident reported. No data loss reported. The network connection was used for its intended purpose.
But consider what is available to that device during those eight hours, even if the technician has no malicious intent and the device carries nothing deliberately harmful.
On a typical Indian NBFC, bank, or manufacturing network without network access control, a device connected to the server room port receives an internal IP address and joins the corporate LAN. From there, it can typically reach the file server, the email server, other connected workstations, the network printer, and, depending on network configuration, internal applications including core banking or ERP systems.
This is not a hypothetical attack scenario. This is the default behaviour of most Indian corporate networks when a new device connects.
Now consider what happens if that device is carrying something the technician is unaware of. A credential-harvesting Trojan picked up from a compromised website. Malware introduced via a USB device at a previous client site. An old remote access tool that a previous client’s IT team installed and never removed. None of these require the technician to do anything. They are passengers on the device, and they are now passengers on your network.
The malware’s job is patient. It does not act immediately. It maps the environment. It identifies the most valuable targets. It caches what it finds. When the technician disconnects at 5 PM and the laptop leaves your building, what the malware found in your network does not leave with the laptop. It may have already sent it somewhere else.
Supply chain and vendor portal attacks are now the preferred entry point for India’s BFSI sector. Ransomware usually walks in through vendor access or unpatched software. Eventus Security
The vendor laptop is one of the most efficient delivery mechanisms for this category of attack precisely because it bypasses the controls that protect the perimeter. It does not need to defeat your firewall. It is inside your firewall before it even connects to your network.
The Scale of This Problem in India
India’s BFSI sector now experiences cyberattacks at 1.6 times the global average, while reported incidents have risen from 1.4 million in 2021 to 2.9 million in 2025. Crnasia
Verizon reported nearly 30% of data breaches in 2025 involved third-party suppliers. FortifyData
Over 40% of manufacturers had breaches tied to third parties. DeepStrike
When a breach originates from a third-party system, the average cost to remediate it is now nearly $4.8 million. FortifyData
For Indian financial institutions specifically, the IBM cost benchmark puts the average financial-sector breach in India at ₹40.9 crore. Higher than any other industry.
The mean time to contain a breach in India stands at 263 days and continues to rise, highlighting widening challenges in cyber response and remediation. Crnasia
263 days. That is the time between the moment of compromise and the moment of containment in the average Indian breach. During those 263 days, the attacker is operating inside the network. Drawing data. Moving laterally. Building persistence. Identifying targets.
The vendor laptop that connected in January may still be yielding results for the attacker in October.
The scale of this risk is not speculative. A malware incident targeting a third-party vendor portal associated with ICICI Bank was reported in 2025. This incident reflects a growing pattern of supply chain attacks targeting India’s banking sector through vendor access pathways rather than direct infrastructure. Eventus Security
The Everest Ransomware Group compromised two Indian banks through a shared technology vendor in April 2026, which we covered in detail in an earlier blog. They did not attack the banks directly. They attacked the vendor ecosystem the banks shared.
CISOs are concerned about third-party and supply chain exposure as financial institutions grow more dependent on shared technology providers, cloud platforms, and API-driven integrations. A single vendor disruption can cascade across multiple financial institutions simultaneously because the sector operates on concentrated technology ecosystems. Crnasia
Why Existing Controls Do Not Solve This
When I raise the vendor laptop problem with IT heads, the response I hear most often is one of three things.
- “We require vendors to use our VPN.”
- “We have a visitor policy that requires them to sign an NDA.”
- “Our firewall would catch anything malicious.”
Each of these is a real control. None of them addresses the specific problem.
- The VPN argument. A VPN authenticates the user and encrypts the tunnel. It does not verify the security posture of the device using the VPN. A compromised laptop with valid VPN credentials connects to your network through an encrypted tunnel. The encryption protects the connection. It does not protect you from what the device is carrying.
- The NDA argument. An NDA creates legal accountability for intentional misuse of confidential information. It does not stop malware that the technician is unaware of. The technician who signs the NDA and carries a Trojan on their laptop is not violating the NDA. They are an unknowing carrier of a threat that the NDA was never designed to address.
- The firewall argument. A firewall monitors traffic at the network perimeter. It inspects what comes in from outside. A device that is already inside the network, connected directly to an internal port, is behind the firewall. The firewall does not see its internal traffic. It does not monitor what it scans, what it copies, or what it sends to the cloud through the outbound connection the technician uses to do their job.
Each of these controls is addressing a different threat. None of them is addressing the specific question: what is this device, and what should it be allowed to reach on my network?
What Governed Vendor Access Actually Looks Like
A well-governed vendor access process changes what happens at the moment of connection.
Before the technician arrives, the vendor session is documented. What system are they accessing? What specific tasks will they perform? What is the minimum network access required for those tasks? How long will the session last? Who is the internal owner of this session?
When the technician connects their device, it is not simply given an IP address and placed on the corporate LAN. The device is checked at connection time. Is it a registered device? What is its security posture? Does it meet the minimum standard required for network access?
Based on those answers, the device is placed in a specific network segment. Not the full corporate LAN. A restricted segment with access only to the specific systems required for the specific job. The core banking patch requires access to the core banking application server. The technician’s laptop is given access to that server. Not to the file server, the email server, or the workstations of the finance team.
The session is logged in real time. Every connection the device makes is recorded. Every file transfer is logged. Every system it reaches is noted. When the session ends, the access is automatically revoked.
If the device tries to connect to a system outside its authorised scope, the attempt is flagged. If the device displays behaviour consistent with network scanning, the session is flagged for review.
This is what the IT head at the Mumbai NBFC needed. Not more suspicion of the vendor. More governance of the device.
What EasyNAC Does at the Moment of Connection
EasyNAC is the network-layer control that makes this governance operational without requiring switch changes or network reconfiguration.
When the vendor’s laptop connects to the server room port, EasyNAC identifies it immediately as a new, unregistered device. Not a device that has been to this office before. Not a device on the approved device list. A new, unknown network entity.
The policy defined for that port automatically places the device in the appropriate VLAN for vendor access. The vendor VLAN has connectivity to the systems the vendor legitimately needs. It does not have connectivity to anything else.
The IT head receives a notification that a new device has connected. He confirms it is the expected vendor session. The device continues in the restricted VLAN. If the IT head does not confirm, the session can be held in the quarantine VLAN until verified.
Every connection the vendor’s laptop makes is logged in real time. If the device starts scanning the network beyond its documented scope, EasyNAC generates an alert. If the device attempts to connect to a system it has no authorised reason to reach, the connection attempt is blocked and logged.
At 5 PM, when the technician disconnects, the session record is complete. What systems were accessed, for how long, and what traffic was generated? The VLAN assignment is automatically revoked. The network returns to its baseline state. There is no lingering access, no orphaned session, no credential cached on a port that the vendor technician can use remotely later.
The IT head who has EasyNAC in place does not need to trust that nothing went wrong during those eight hours. He has a log that shows exactly what happened.
The Checklist Every IT Head Should Run Before Any Vendor Device Connects
These steps apply to every vendor, every technician, and every device, regardless of how long the relationship has been in place or how trusted the vendor is.
- Before the visit: Document the specific systems the vendor needs to access. Define the minimum network access required. Create a vendor session record with the date, time window, technician name, and scope. Confirm that EasyNAC or equivalent network access control is active on the port they will use.
- At the moment of connection: Verify the device is placed in the appropriate restricted network segment automatically. Confirm that the access is limited to the documented scope. Ensure the session is being logged in real time.
- During the session: Maintain visibility of the active session. If the vendor needs access to a system outside the documented scope, this should require explicit approval, not a helpdesk ticket that gets actioned without review.
- After the visit: Review the session log. Confirm that the access scope was not exceeded. Revoke any temporary credentials issued for the session. Close the vendor session record.
This process sounds more formal than what most Indian companies currently do. That is the point. Most Indian companies wave the vendor into the server room and wave them out eight hours later. The formality is what closes the gap.
The Broader Pattern
The vendor laptop is one instance of a broader problem that runs through every blog we have published on this site in 2026.
The Bank of Baroda breach came through a single email credential. The Everest ransomware attack on two Indian banks came through a shared technology vendor. The Kudankulam contractor breach came through a commercial data centre server with inadequate controls. The Tata Technologies breach came through the technology subsidiary’s IT environment. The Two Banks, One Vendor case showed how a single vendor compromise can cascade across multiple institutions simultaneously.
In every one of these incidents, the entry point was a trusted relationship whose device or environment was not governed to a standard proportionate to the access it received.
The vendor is trusted. That is true and appropriate. The device the vendor connects is not automatically trusted by the fact of the relationship. These are two different questions, and most Indian companies have only answered the first one.
Instead of treating vendor security as a procurement or compliance exercise, institutions are starting to treat vendors as extensions of the enterprise itself. Crnasia
Treating vendors as extensions of the enterprise means governing their device access with the same rigour applied to enterprise devices. Not more suspicion. More governance. More visibility. More control over what each device can reach and for how long.
Final Thought
The IT head at the Mumbai NBFC waved the technician goodbye at 5 PM and went home.
He had no reason to think anything had gone wrong. The job was done. The vendor was trusted. The technician had been here before. Nothing unusual happened during the day.
What he did not have was a log showing what the device had done for eight hours on his network. What systems it had reached. What traffic it had generated. Whether it had attempted to connect to anything outside the scope of the maintenance job.
He had done everything a reasonable IT head would do. He had checked the vendor. He had verified the work order. He had been present for the visit.
He had not checked the device.
The check that was missing is not a complicated one. It is a network access control policy that says: every device that connects to this network is identified, placed in an appropriate segment, and monitored for the duration of the session. Trusted vendors get appropriate access. Not unchecked access.
That distinction, between appropriate and unchecked, is the governance gap that the vendor laptop exploits every time it connects to an Indian corporate network without a check.
Closing it does not require distrusting your vendors. It requires knowing what their device is doing while it is on your network.
EasyNAC provides real-time network visibility and access control that identifies every device the moment it connects to your network, places it in the appropriate segment based on your policy, and logs every connection for the duration of the session. It deploys without switch changes or network reconfiguration, making it practical for Indian banks, NBFCs, and manufacturers to govern vendor device access from the first connection. If you want to understand what currently happens when a vendor’s laptop connects to your network, we can show you in a 30-minute demo.
