The second factor starts at the Windows login.
A private life insurer put multi-factor authentication in front of the desktop sign-in as well as the applications behind it, and let only registered, checked devices reach either.
Where they started.
The customer is one of India's leading private life insurers, working through branch offices and a workforce that reaches policy, servicing and claims applications from wherever the day starts.
Insurance is regulated work. IRDAI guidance and the insurer's own security policy expect strong identity controls, a traceable record of who reached what, and continuity that survives the loss of a site. The access model had to carry all three without making an ordinary morning harder.
The gap it wanted closed sat before the applications. A working password on an unregistered laptop was still enough to open a Windows desktop, and everything that desktop could reach afterwards.
What was in the way.
- The login itselfStrong authentication had to cover the endpoint sign-in, not only the applications opened after it.
- Trusted devicesAccess was to come from registered, compliant machines rather than from anything holding a valid credential.
- One directoryWhatever went in had to read from the Active Directory already in use, not keep a second list of people alongside it.
- ContinuityThe access layer had to run across the data centre and its disaster-recovery site, because access failing is work stopping.
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 at the desktopThe Windows sign-in asks for a second factor, so the check happens before the desktop opens rather than at the first application after it.More
- Factors across appsThe same second factor covers the business applications behind the login, configured once rather than integration by integration.More
- Registered devicesAn account is tied to the hardware it was registered on, so a credential that leaves the person it belongs to does not arrive anywhere useful.More
- Posture read firstOperating-system state and security compliance are read before a session opens, every time, not at enrolment only.More
- Application by applicationA user sees and opens the applications explicitly granted to them; the rest are not listed and not reachable.More
- The directory stays the sourceIdentities come from the organisation's Active Directory, so joining, moving and leaving remain one process rather than two.More
- Two sites, one policyThe deployment runs across the customer's data centre and its disaster-recovery site, so access does not depend on one room staying up.More
What changes when the checkstarts at the sign-in
Three consequences of putting the second factor in front of the desktop rather than in front of the applications alone.
The desktop is a checkpoint
Endpoint sign-in stops being the one door in the estate with a single lock on it.
Only known hardware
A registered machine in a state the policy accepts is the condition for a session, so a valid password on an unknown laptop goes nowhere.
Access survives a site
The deployment spans the data centre and its recovery site, so a failover does not take sign-in with it.
“InstaSafe helped us strengthen our access security without adding complexity for our users. The seamless integration with our existing infrastructure, combined with strong identity and device-based controls, enabled us to enhance security while meeting our compliance and business continuity objectives.”
Seven more stories, filtered by sector and by the problem they started with.
All customer stories//Ready when you are//
Put the second factor in front of the login.
A 30-minute walkthrough of what MFA at the Windows sign-in looks like on your own endpoints, and what it costs a user each morning.
Regulated, air-gapped, or on-premise? See deployment options