The first casualty of a sudden move to remote work is often the drawing of the office network. Inside the building, access may have been arranged around a place: the office, the branch, the known machine. Send everyone home and that drawing becomes a work of fiction. During the pandemic, a large business-process company had to extend voice, intranet, file sharing and other applications to staff outside its offices. Its InstaSafe deployment, the vendor says, grew from 500 to 33,000 users in five days.
- InstaSafe sells access to specific enterprise apps and resources, with checks on the person and device.
- Its ZTAA product handles application access; ZTNA also serves legacy and non-browser traffic.
- A customer case study reports the five-day, 33,000-user remote-work expansion.
- A public AWS listing starts at $299 for 20 users and five applications over 12 months.
That number deserves its attribution. It comes from an InstaSafe case study, not a public audit of the customer's systems. Still, it points to the question the company has spent years asking: why should connecting to work mean connecting to the whole workplace? A worker needs a phone system or a finance app. A contractor needs one server. The network connecting those things is infrastructure, not an invitation.
The room with 33,000 doors
The business-process customer's problem was unusually broad. Remote employees needed voice traffic that could tolerate very little delay, plus intranet, file sharing and back-office software. The case study says the firm required clientless login for some users and a single dashboard for administrators. InstaSafe describes an integrated setup for those applications with MFA, device checks and restrictions by location and time. It reports the leap to 33,000 users, while the customer remains unnamed.
There is a temptation to treat that statistic as the entire story. The more transferable part is the shape of the access. Instead of asking whether the employee has entered the company network, an administrator asks which service that employee should reach. A lost credential then has less useful territory to explore. That does not make a compromised account harmless; it makes the permission attached to it smaller.
A badge is not a building pass
InstaSafe calls this zero trust access. The phrase has suffered from years of sales presentations, but its basic test is plain: verify the user and device, decide what resource is allowed, and record the decision. InstaSafe's application access product, ZTAA, presents entitled applications rather than a general route into the network. Its ZTNA product covers the awkward systems that do not live comfortably in a browser: thick-client ERP software, custom TCP or UDP services and other old but essential tools.
This distinction matters because the neatest security diagram is no use when a payroll application still speaks a custom protocol. InstaSafe's network product opens a session to a selected resource; the company says its gateway drops unsolicited traffic and uses single-packet authorization before responding. On the application side, a user sees only the services their group is entitled to use. Identity, single sign-on, MFA, device posture and logging sit in the same product family.
“Trust based on network location was already a liability.”InstaSafe, describing its 2012 founding premise
The firm was founded in Bengaluru in 2012 by Sandip Kumar Panda and colleagues including Biju George and Prashanth Guruswamy. The founding proposition was early, but hardly mystical: being at the right address on a network does not prove that a person deserves access. The company joined a Microsoft Ventures accelerator in 2014; in 2017, ABM Knowledgeware announced an investment commitment of up to 15 crore rupees, then about $2.2 million. An earlier angel investment had come from Indian Angel Network and CIO Angel Network.
The customer is often a contractor
Look beyond the pandemic case and the pattern gets more interesting. A bank case study describes outside support staff needing its mail server from their own mobile devices, without receiving access to the surrounding network. A confectionery manufacturer moved cloud ERP while web applications stayed in its data centre; its story says it retired OpenVPN and administered access through one console. A public-sector insurer needed contextual rules and MFA, but wanted the whole setup on its own hardware, mirrored to a disaster-recovery site.
Those are three different buying motives: limit a vendor, simplify a mixed cloud and on-premise estate, and keep sensitive access decisions inside a regulated organisation's own boundary. InstaSafe publishes customer logos including Tata, Siemens, HDB Financial Services and Asian Paints, and says more than 150 enterprises across five continents use its products. The public case studies often omit customer names, so the specific results should be read as the company's account of those deployments.
What the smaller door costs
A buyer can find one unusually concrete price point. InstaSafe's AWS Marketplace listing shows 12-month contracts for five applications: $299 for 20 users, $649 for 50, and $1,199 for 100. Those are listing tiers, not a universal enterprise quote. A larger estate, different support terms or on-premise deployment calls for a conversation with the vendor. The practical cost also includes mapping applications, assigning groups and reviewing privileges that have accumulated over years.
These figures describe one marketplace offer. They are not a quote for the 33,000-user customer or for an on-premise deployment.
Its commercial model uses direct sales and partners. Ingram Micro signed a global distribution agreement in 2020; the company later announced a partnership with Pace InfoSolutions. That channel strategy fits a product whose deployment may depend on a customer's existing identity directory, application inventory and local support. It also places InstaSafe in a crowded field: a buyer may weigh it against a conventional VPN, or access products from Zscaler, Cloudflare, Netskope, Cisco Duo, Fortinet or Akamai.
The question worth stealing
A company does not need to buy a new platform to borrow InstaSafe's most useful habit. Take one application that remote staff use. Write down exactly who should reach it, from which devices, and what evidence an auditor should see later. Then ask whether today's access route grants anything more. This exercise is dull in the best possible way. It turns an abstract security ambition into a list of permissions that someone can actually check.
The method has limits. A legacy system may require protocols the browser cannot carry; a device-check rule may exclude workers on unmanaged equipment; an on-premise requirement can change deployment effort and cost. A hurried rollout is only as good as its inventory of users and applications. Those are not objections to smaller permissions. They are the reason to test them against real work before announcing that the network has vanished.
InstaSafe's five-day story is therefore less a tale of security magic than of a company that chose a narrower unit of access. In a crisis, the old question was how to get 33,000 people onto the network. The better one was what each of those people came to do.