Contextual access and MFA, inside their own data centre.
A public-sector insurer put role-, device- and time-aware access in front of its applications, with multi-factor authentication built in and the entire stack running on its own hardware.
Where they started.
The customer is one of the largest public-sector insurance companies in India, working through a national network of branch offices and agents.
The work is financial and regulated: RBI and IRDAI guidance sits over it, alongside the organisation's own security policy. So the requirement was written tightly. Access to an application had to depend on who was asking, what role they held, which device they were on and what time it was, and it had to be backed by multi-factor authentication with a wide choice of factors, since not every user carries the same thing. A reviewer also had to be able to see, afterwards, who reached what.
The last condition ruled out most of the market. The solution had to be installed as an on-premise deployment inside the organisation's own private data centres, with nothing about the decision leaving the building. It also had to stand up across a data centre and a disaster-recovery site, because for an insurer of this size access failing is work stopping.
What was in the way.
- Context requiredAccess had to be decided on user identity, role, device and time of access together, not on network location.
- Device stateA device's security posture had to be verified before access was granted, every time: its operating-system version, and whether antivirus was present and current.
- Many factorsAuthentication had to cover one-time codes, time-based codes, fingerprint and face, hardware tokens and push, because the user base is not uniform.
- Data at the edgeA granted application still put financial and customer records on an endpoint, and the ways they left it had to be closed off.
- Evidence for the reviewAccess had to be visible centrally and traceable afterwards, in a form the organisation's auditors and regulators already read.
- Their own racksThe whole solution had to be installed inside the organisation's private data centres, not consumed as a service. It also had to be mirrored to a disaster-recovery site, because access could not stop when one room did.
What was put in place.
Each control below has its own page. If a row makes a claim, the link is where you check it.
- MFA inbuiltOne-time and time-based codes, biometrics, hardware tokens and FIDO, speaking SAML, RADIUS and TACACS, applied to every user rather than to an administrative few.More
- Posture checkedA session opens only after the device's antivirus state and operating-system version have been read against the policy.More
- Device boundAccounts are tied to registered hardware: one corporate laptop and one registered mobile per user, identified by machine and processor identifiers rather than by a name a user types.More
- Directory-backedIdentities come from the organisation's own Active Directory, so joining, moving and leaving stay one process and the access layer keeps no second list of people.More
- Granular policyAccess is granted per user, per group and per role, and a user is shown only the applications granted to them; the rest are neither listed nor reachable.More
- Inside the windowPolicies carry a time restriction as well as a role, so access to an application is open during the hours the business says it should be and closed outside them.More
- Controls in sessionClipboard control, download control, application filtering and an identifying watermark over on-screen content apply inside the session, so a granted application is not automatically an exportable one.More
- Logged for auditEvery decision is written as a typed event and exported to the SIEM the security team already runs, which is what turns real-time monitoring into an audit that can be answered later.More
- On their hardwareController, gateway and the MFA service all run inside the customer's own data centre, with no dependency on ours. The same stack runs again on a configured disaster-recovery site, so a failover does not take access with it.More
What stays inside the boundarywhen the whole stack does
Three consequences of deploying the policy engine, the gateway and the second factor on the customer's own hardware.
The record stays too
Identity, device and time decide each session, and the log of that decision reaches the organisation's own SIEM. An audit is answered from inside the boundary rather than reconstructed afterwards.
Built for uptime
The design runs across a configured data centre and disaster-recovery pair with automatic failover. That is the part a regulator asks about, and the part a working day depends on.
One system, not three
MFA, contextual policy and the endpoint controls are one platform, so there is no third-party integration to procure, patch and explain, and growth is a configuration change in the same racks.
“InstaSafe is one comprehensive Zero Trust solution that combines contextual access, endpoint controls, MFA with detailed analytics and reporting feature. On-premise deployment process is smooth. Easy to scale solution with no latency issues”
Seven more stories, filtered by sector and by the problem they started with.
All customer stories//Ready when you are//
Run the whole stack inside your own boundary.
Controller, gateway and MFA on your hardware, in your data centre. A 30-minute walkthrough of what that deployment actually involves.
Regulated, air-gapped, or on-premise? See deployment options