A few months ago, I was sitting in a security review meeting with the IT head of a mid-size NBFC in Pune.
They had invested thoughtfully in their security stack. A next-generation firewall from a reputable vendor. Endpoint detection and response is deployed across every managed laptop and desktop. A SIEM feeds alerts to a managed SOC. Email security. Multi-Factor Authentication on their banking applications. Regular VAPT cycles.
It was a serious, well-funded security posture. Much better than most organisations of their size.
I asked one question: “Can you tell me right now, with confidence, how many devices are connected to your network across all your branches?”
The IT head paused. Looked at his screen. Looked at me.
“Approximately,” he said. “But not exactly.”
That gap between approximately and exactly is where most Indian bank and NBFC breaches begin. And it is the gap that no amount of firewall spend, no endpoint agent, and no SIEM rule will close. Because none of those tools are designed to answer that question.
Only one category of tool is. And it is consistently the last one that Indian financial institutions buy.
Why NAC Always Gets Pushed to the Bottom of the Procurement List
Network Access Control has been a recognised security discipline for over fifteen years. It is mandated in frameworks used by financial institutions across the US, Europe, and Southeast Asia. Every serious VAPT finding at an Indian bank in the last three years has included a recommendation for improved network access visibility.
And yet, when I ask CISOs and IT heads at Indian banks and NBFCs where NAC sits in their procurement priority, the answer is almost always the same: next year.
There are three reasons this happens, and they are worth naming directly because they shape the entire conversation.
The first reason is sequence. Security budgets in India were built sequentially. Firewall first. Then antivirus. Then email security. Then endpoint protection. Then SIEM. NAC came later in the global security maturity model, which means it arrived at Indian procurement conversations after budgets were already committed to the earlier layers. By the time a CISO has renewed the firewall contract, paid for EDR licenses, and funded the SOC, the NAC line item looks like a luxury.
The second reason is the perception of redundancy. A CISO who has a firewall, an EDR, and a SIEM can make a reasonable-sounding argument that they have network control, device control, and visibility covered. That argument is wrong in one specific and critical way. But it sounds plausible enough to win a budget discussion against a tool most board members have never heard of.
The third reason is that NAC vendors have historically made the product sound complex. 802.1X authentication. RADIUS server integration. Switch-level port enforcement. Agent-based profiling. These terms create an impression that NAC implementation requires a network overhaul. For an IT head managing 20 branches and a team of six, that impression ends the conversation before it starts.
All three of these reasons are addressable. But they need to be addressed directly, not papered over with a product brochure.
What Your Current Security Stack Actually Sees and What It Misses
This is the conversation that changes how CISOs think about the problem. Not a product pitch. A capability map.
Your firewall inspects traffic at the network boundary. It enforces rules about what can come in and go out. It is excellent at its job. What it cannot do is tell you about a device that is already inside the boundary. A laptop that plugged into a LAN port in your Nashik branch this morning is behind the firewall. The firewall had already let it through by the time it connected to the internal switch. If that device is unregistered, unknown, or compromised, the firewall has no mechanism to flag it.
Your antivirus and EDR solution protects managed endpoints. Devices where an agent has been installed. It monitors behaviour, detects malware, and generates alerts. What it cannot protect is a device without an agent. The vendor engineer’s laptop. The network-connected CCTV camera. The ATM maintenance terminal. The relationship manager’s personal iPad. The Wi-Fi printer was installed three years ago by a contractor. None of these has your EDR agent. None of them are in your EDR’s visibility.
Your SIEM aggregates logs from systems it has been configured to receive from. It correlates events and surfaces anomalies. It is only as good as its data sources. If a device connects to your network and does not generate a log in any system your SIEM is watching, it is invisible to your SIEM. The SIEM is not designed to discover unknown devices. It is designed to analyse events from known ones.
What none of these tools answer is the foundational question: what is connected to my network right now?
Network Access Control answers this question by operating at the network layer itself, at the point where devices connect. Before a device can communicate on the network, NAC identifies it. It checks whether the device is registered and authorised. It classifies the device by type. It enforces the appropriate access policy. And it logs every connection event in real time.
This is not a duplicate of what your other tools do. It is the layer underneath all of them, the one that tells you what the other tools are actually protecting against.
Why Indian Banks and NBFCs Specifically Need This Layer
The capability gap that NAC closes exists in every organisation. But it is wider and more consequential in banking environments for specific structural reasons.
Branch networks multiply the attack surface. An NBFC with 25 branches does not have one network. It has 25 connected network environments, each with its own switches, local devices, and physical access points. A contractor who installs a new biometric attendance system in the Kolhapur branch connects a device to the LAN. That device may or may not be registered with the IT team in the head office. It may remain connected for months. The IT team may never know it is there unless they receive a specific complaint. NAC removes this uncertainty by flagging every new device at the moment it connects, regardless of which branch it appears in.
Vendor access is permanent and unmonitored. As we covered in our earlier blog on third-party vendor risk, most Indian financial institutions have between 25 and 60 active vendor relationships. Software vendors. Hardware support engineers. ATM maintenance teams. Network infrastructure providers. Each of those relationships involves a device that connects to the network at some point. In most institutions, those devices are never formally registered, their connections are never logged, and their sessions are never time-limited. NAC creates a governed perimeter around every vendor device connection.
RBI now requires it, in substance if not by name. The RBI IT Governance, Risk, Controls and Assurance Practices Directions, effective April 1, 2024, require regulated entities to maintain an operational resilience framework for their entire IT environment, to identify and categorise information assets based on criticality, and to establish comprehensive vendor risk assessment processes and controls. The Directions mandate the identification and categorisation of information assets based on confidentiality, integrity, and availability, with particular attention to criticality. You cannot categorise assets you do not know exist. You cannot assess vendor risk for connections you cannot see. The regulatory obligation for device visibility and network access governance is real. NAC is the operational control that satisfies it. CimcorSaachiHRMS
The DPDP Act creates additional accountability. Under the Digital Personal Data Protection Act, an organisation that holds customer personal data must demonstrate reasonable security safeguards. An unknown device with access to a network segment holding customer data is a documented security gap. In a regulatory investigation following a breach, the absence of NAC in a bank or NBFC environment will be a finding, not a footnote.
Hardware NAC Versus VM Appliance. Why the Deployment Model Matters
This is a conversation that rarely happens in Indian procurement discussions because the focus jumps immediately to price. It deserves more attention because the deployment model determines the operational reliability and security of the NAC solution itself.
The NAC solution, deployed as a virtual machine appliance, runs on your existing hypervisor infrastructure. It shares compute resources with other systems. It requires OS patching and maintenance. Its availability is tied to the health of the hypervisor cluster it runs on. If the hypervisor has a problem, your NAC has a problem. And critically, a VM-based NAC solution is itself a software system running on a network it is supposed to be monitoring, which creates a circular dependency that complicates incident response.
A dedicated hardware NAC appliance is purpose-built for the function. It has no operating system maintenance overhead beyond firmware updates. It does not compete for compute resources. It is not dependent on the availability of your virtualisation infrastructure. When a security incident occurs and your virtual environment is under stress or compromise, a hardware appliance continues operating independently.
For a bank or NBFC with a distributed branch network, hardware appliances deployed at each network aggregation point also provide a more reliable enforcement architecture. The NAC policy is enforced at the hardware level, not dependent on a software service running somewhere in the data centre.
EasyNAC’s hardware appliance model is specifically designed for this requirement. It plugs into the existing network as a passive monitoring and enforcement device, requires no changes to the switch infrastructure, no 802.1X deployment across the branch network, and no agent installation on endpoints. A branch with 40 devices can have its network access controlled and monitored within hours of deployment, without a network reconfiguration project.
This is not a small distinction. The reason many NAC projects in India stall at the pilot stage is that the traditional enterprise NAC vendors require infrastructure changes before the product works. EasyNAC removes that dependency entirely.
The Indian Buyer’s Cost Trap and How a Smart CISO Escapes It
I want to be direct about something specific to how security procurement happens in India, because it explains why organisations end up with NAC solutions that do not actually solve the problem.
The conversation usually goes like this. A CISO gets budget approval for NAC. Three vendors are evaluated. Two enterprise-grade solutions come in at high cost. One budget option comes in at a fraction of the price. The budget option wins.
Six months later, the budget option is deployed on 20% of the network. The remaining 80% is still uncontrolled because the cheaper solution does not scale to multi-branch environments without high additional cost. The solution does not integrate with the existing Active Directory. The reporting module does not generate the format the compliance team needs for the RBI audit. The vendor’s support team is responsive until the sale is closed, and then difficult to reach.
The CISO spent less money and has more problems than before.
The right framework for NAC evaluation is not cost per unit. It is capability per rupee, measured against the specific operational environment and compliance requirements of a bank, NBFC, or financial institution.
What to Actually Evaluate When Procuring NAC. A Simple CISO’s Checklist
These are the criteria that matter. Not the ones that look impressive in a product sheet.
- Agentless device discovery. Can the solution identify every device on the network without installing an agent on each device? This is the difference between controlling managed endpoints and controlling the actual network. An agent-based NAC solution leaves every unmanaged device invisible. In a bank environment with ATM terminals, network printers, IP cameras, biometric systems, and vendor devices, agentless discovery is not a feature. It is the fundamental requirement.
- Switch independence. Does the solution require 802.1X configuration on your switches, or does it work with your existing switch infrastructure? 802.1X deployment across a 25-branch network is a months-long infrastructure project with significant disruption risk. A switch-independent NAC solution deploys in a fraction of the time and cost.
- Device classification granularity. Can the solution distinguish between a domain-joined laptop, a guest device, a VOIP phone, a network camera, and a vendor engineering workstation? The policy you enforce should be different for each. A solution that classifies devices into two or three categories does not give you the control you actually need.
- Response capability beyond alerting. When an unrecognised device connects, what can the solution do? Alert only? Quarantine the device to a restricted VLAN? Block it entirely? The appropriate response depends on the device type and the network segment. You need graduated response options, not a single alert email.
- Multi-branch, centralised management. Can a single administrator in the head office see and manage device access across all branches from one console? This is non-negotiable for any institution with more than two locations. A solution that requires per-branch administration is not an enterprise solution.
- RBI compliance reporting. Can the solution generate reports that directly support your RBI IT Governance compliance evidence? Access logs, connection history, device inventory, policy enforcement records. The CISO who can hand an auditor a real-time device inventory with historical access logs has a fundamentally different regulatory conversation than the one who cannot.
- Integration with Active Directory and existing identity management. Does the solution use your existing user and device directory for policy enforcement? The NAC solution that requires a separate identity database doubles your administrative overhead and creates synchronisation risk.
- India-based support and deployment capability. This is specific to the Indian market and is frequently overlooked. An enterprise NAC product with North American support hours and no local implementation expertise will cause deployment delays that negate the cost savings. Evaluate the vendor’s ability to deploy, configure, and support the solution in the Indian timezone and with knowledge of Indian network environments.
The Value Conversation Every CISO Should Have With Their Board
The reason NAC gets deprioritised in budget discussions is partly about cost and partly about how the value is presented. A CISO who walks into a board meeting and says “we need NAC for Rs 15 lakhs” will get a different response than one who frames the conversation correctly.
The correct frame is not the cost of NAC. It is the cost of not having it.
A vendor device that connects to your network and exfiltrates customer data over 18 days, which is the documented dwell time in the Everest ransomware attack on two US banks through a shared vendor, costs orders of magnitude more than any NAC deployment. The regulatory response to a breach of that nature under RBI guidelines and the DPDP Act involves penalties, mandatory remediation, operational restrictions, and reputational damage.
The value of NAC is not what it does. It is what it prevents. And the prevention value is measurable in two ways that resonate with boards: the regulatory penalty avoided and the incident response cost that never occurs.
A CISO at an Indian NBFC who can demonstrate that NAC deployment reduced their RBI audit finding count, closed a documented gap in their IT governance framework, and gave them a real-time device inventory they can show the Board at any moment has made a governance argument, not a technology argument. That is the argument that wins the budget.
What Deploying EasyNAC at an NBFC Actually Looks Like
The reason many CISOs hesitate at NAC is the deployment picture they have in their head, which comes from experiencing enterprise NAC products that require network redesign before they work.
EasyNAC is purpose-built to remove that barrier. It operates as a hardware appliance that sits passively on the existing network. No switch changes. No 802.1X configuration. No agent deployment. No network reconfiguration.
At a mid-size NBFC with a head office and 25 branches, a phased EasyNAC deployment can achieve full network visibility across the entire estate in weeks rather than months. The head office sees every device across every branch in a single management console. New device connections are flagged in real time. Vendor access sessions are logged with timestamps. Unknown devices are quarantined automatically by policy.
The IT team does not need additional headcount to manage it. The learning curve is what the name promises: easy.
For the CISO who has been told NAC is too complex, too expensive, or too disruptive for their environment, this is the conversation worth having. Not about the product. About the gap in their current security posture, that nothing in their existing stack is designed to close.
Final Thought
I have had the same conversation with IT heads at banks and NBFCs across Maharashtra and Mumbai for the past several years. They are smart, experienced professionals who have built genuinely capable security environments. The gap in their thinking is not about effort or intelligence. It is about the question they are not asking.
Every security investment they have made answers a specific question. The firewall answers: What traffic should be allowed to cross my boundary? The endpoint agent answers: Is this device behaving maliciously? The SIEM answers: What patterns in my log data indicate a threat?
Nobody asked: what is actually connected to my network right now?
In a branch banking environment with hundreds of devices, dozens of vendor relationships, and a network that changes every week as new equipment is installed, decommissioned, or connected, that question has a different answer every single day.
A CISO who cannot answer that question confidently is managing a security posture they cannot fully see. They are defending a perimeter they have never completely mapped.
NAC does not replace the firewall. It does not replace the EDR or the SIEM. It completes the picture that those tools started. It tells you what is actually there so that everything else you have invested in is protecting the right things.
The question is not whether your bank or NBFC needs NAC. It is when you will stop accepting that you do not know exactly what is connected to your network.
At Skeletos IT Services, we deploy EasyNAC for Indian banks, NBFCs, and financial institutions as a plug-and-protect Network Access Control solution. No switch changes. No network reconfiguration. Real-time visibility across every branch from day one. If you want to know exactly how many devices are on your network right now, we can show you in a 30-minute demo.
