IRDAI ICS Annexure III Item 14 requires that all access to organisational systems be authenticated through a centralised authentication mechanism. This is not a recommendation to deploy SSO for user convenience. It is a compliance obligation with a specific architectural requirement: a single identity source, a unified authentication layer covering all systems, consistent MFA enforcement, and a centralised audit trail of all authentication events.
Most insurance IT teams have deployed SSO for some applications. The compliance gap is almost always in coverage and architecture. SSO deployed for cloud SaaS applications but not for legacy policy administration systems. MFA enforced at the web application layer but not for server management or database access. Authentication events logged per application in separate systems rather than consolidated into a single, queryable audit trail.
Item 14’s centralisation requirement means that every authentication event, regardless of which system the user is accessing, must route through the same identity layer and produce a record in the same audit trail. A user authenticating to a cloud CRM through SSO and the same user authenticating to a legacy claims system through a separate login page are two different authentication architectures. Item 14 requires the former for all systems.
This blog covers what Item 14 requires technically, how a centralised authentication architecture is implemented, and what compliance evidence it produces. All item references are drawn from the IRDAI ICS Annexure III checklist and Akku’s IRDAI compliance mapping documentation.
Item 14’s centralised authentication requirement has four distinct technical components. Each component has implementation requirements that go beyond simply deploying an SSO solution.
Centralised authentication begins with a single identity store. If users exist in multiple directories, an Active Directory for on-premises systems, a separate cloud directory for SaaS applications, and application-specific user databases for custom systems, authentication cannot be truly centralised because the identity layer is fragmented.
A single identity source means one directory holds all workforce identities and serves as the authoritative source for all authentication decisions. Applications that currently maintain their own user databases must be migrated to authenticate against the centralised directory. Legacy systems that cannot support modern authentication protocols must connect through credential replay or protocol bridging rather than maintaining separate credentials.
Akku’s unified cloud identity store serves as this single source. It is designed to be the only identity store an organisation needs, providing identity credentials to modern SaaS applications, legacy systems, and custom internal applications. Directory synchronisation capabilities maintain consistency for organisations migrating from existing Active Directory or LDAP environments.
A unified authentication layer means every application routes authentication through the same identity provider, regardless of the protocol it supports. Modern SaaS applications authenticating via SAML, OIDC, or OAuth connect directly to the Akku IdP. Legacy applications that do not support modern federation protocols connect through SSO with credential replay, which extends centralised authentication coverage to applications that cannot be federated natively.
This is the coverage gap that most partial SSO deployments carry. The applications that support SAML are covered. The legacy policy administration system, the claims processing platform, and the internal tools that predate modern authentication protocols are not. Item 14’s requirement covers all systems, not only those with modern protocol support.
Akku’s 500-plus pre-built connectors provide plug-and-play integration for common SaaS applications. Credential replay extends coverage to legacy applications without protocol support. Desktop SSO extends the centralised authentication layer to domain-joined workstations, covering the local login layer that application-level SSO does not address.
Centralised authentication enables consistent MFA enforcement because MFA policy is applied at the identity provider layer, not at each individual application. When MFA is configured at the IdP level, every application that routes authentication through the IdP inherits MFA enforcement without requiring separate MFA configuration per application.
Item 14’s centralisation requirement makes Items 52, 64, and 65’s MFA requirements technically achievable at scale. Enforcing MFA for privileged access to network devices, for remote access to critical applications, and for all user access to sensitive systems requires a centralised authentication layer through which MFA policy can be applied consistently.
Akku’s Adaptive MFA is configured at the platform level and applies to all connected applications. Step-up authentication for high-sensitivity access, device-aware authentication for endpoint compliance verification, and geo-location based access restrictions are all applied through the centralised authentication layer.
A centralised authentication layer produces a centralised authentication audit trail as a structural byproduct. Every authentication event across every connected application generates a structured log record in a single audit trail, with actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome.
This is the audit trail that IRDAI Items 2, 35, and 274 require: a complete record of all access to organisational systems, in tamper-evident format, available for regulatory examination on demand. When authentication is fragmented across multiple systems, producing this record requires manual compilation from multiple log sources. When authentication is centralised, the record exists as a continuous, queryable stream.
Implementing Item 14 in an insurance environment requires addressing the specific system landscape that most insurers operate: a mix of cloud SaaS applications, on-premises legacy systems, custom-built internal tools, and infrastructure management interfaces.
Cloud SaaS applications supporting SAML 2.0, OIDC, or OAuth connect to Akku as a centralised IdP through standard federation. The connection is typically configured in minutes using Akku’s pre-built connector catalogue. Authentication events from these applications flow into the centralised audit trail automatically.
Legacy policy administration systems, claims platforms, and on-premises line-of-business applications require one of two approaches depending on their technical capabilities. Systems that support LDAP authentication can authenticate against Akku’s cloud directory directly or through directory synchronisation. Systems with no directory integration capability can be covered through SSO with credential replay, which intercepts the application’s login form and injects credentials managed by the centralised identity layer.
Server management consoles, database management interfaces, and network device management systems require PAM-layer coverage rather than application-layer SSO. AkkuReka’s outbound worker architecture deploys in the same network segment as the target systems and routes privileged sessions through the centralised authentication layer. This extends Item 14’s centralised authentication requirement to the infrastructure layer, covering the access paths that application-level SSO does not reach.
The centralised audit trail is a structural output of routing all authentication through a single identity layer. No additional log aggregation configuration is required for the authentication event stream. Privileged session recordings from SMARTAudit Trails and endpoint compliance events from MDM and GPO Manager supplement the authentication audit trail with activity-level evidence.
A correctly implemented centralised authentication architecture produces four categories of compliance evidence relevant to IRDAI ICS requirements.
Authentication event log covering every login attempt across all connected systems with actor identity, timestamp, source IP, device, location, MFA method, and outcome. This satisfies Items 2, 5, 35, 54, 55, and 274.
MFA enforcement evidence showing that every authentication event to covered systems included a successful MFA challenge. This satisfies Items 52, 64, and 65 for the systems within the centralised authentication perimeter.
Access governance records covering provisioning, de-provisioning, role changes, and access reviews with full approval audit trails. This satisfies Items 6, 10, 26, 33, 150, 152, 155, 157, 189, and 341 through the IGA and User Lifecycle Manager modules.
Privileged session recordings for every infrastructure-level session brokered through AkkuReka. This satisfies Items 144, 145, 190, and 274 through SMARTAudit Trails.
Akku’s IRDAI mapping shows Cloud Directory and SSO together address Items 14, 50, 135, 176, 204, 298, and 300 across seven total mappings.
Does every system in your organisation, including legacy policy administration platforms and claims processing tools, authenticate users through a single centralised identity layer, or do some systems maintain separate credential stores?
Can you produce on demand a complete authentication event log covering every login attempt across all connected systems for any 30-day period an IRDAI examiner requests, from a single queryable source without manual compilation?
Is MFA enforcement applied at the identity provider layer so that every application inheriting authentication from the centralised IdP automatically enforces MFA, or is MFA configured separately per application with inconsistent coverage?
Do your infrastructure management interfaces, including server management consoles and database management tools, route authentication through the same centralised identity layer as your application-layer SSO, or do they have separate authentication mechanisms?
When an employee’s employment ends, does deprovisioning of their centralised identity result in automatic access revocation across all connected systems simultaneously, or does each system require a separate deprovisioning action?
See how Akku addresses IRDAI Item 14 centralised authentication requirements across cloud, legacy, and infrastructure systems.
Book a conversation with the Akku team to assess your current authentication architecture against IRDAI ICS compliance requirements.
What is the difference between deploying SSO and implementing centralised authentication as Item 14 requires?
SSO deployment typically covers the applications that support modern federation protocols such as SAML and OIDC. Centralised authentication as Item 14 requires covers all systems, including legacy applications that do not support modern protocols, infrastructure management interfaces, and desktop login. The key architectural distinction is that every authentication event routes through a single identity layer that produces a unified audit trail. A partial SSO deployment where some systems authenticate through the IdP and others maintain separate credentials does not satisfy Item 14’s centralisation requirement.
How does credential replay extend centralised authentication to legacy systems?
Credential replay is a technique where the SSO platform intercepts a legacy application’s login form and injects credentials managed by the centralised identity layer, without requiring the application to support SAML, OIDC, or other modern federation protocols. The user authenticates to the centralised IdP with MFA, and the IdP handles the legacy application’s authentication transparently. From the user’s perspective, the experience is SSO. From the centralised audit trail’s perspective, the authentication event is captured at the IdP layer. This extends Item 14’s centralised authentication requirement to applications that cannot be federated natively.
Does Item 14’s centralised authentication requirement apply to privileged infrastructure access as well as application access?
Yes. Item 14 requires that all access to organisational systems be authenticated through a centralised mechanism. This includes infrastructure management interfaces such as server SSH access, database management consoles, and network device management interfaces. These access paths are not covered by application-layer SSO. PAM-layer coverage through AkkuReka’s session proxy architecture extends the centralised authentication requirement to infrastructure access, routing every privileged session through the Akku IAM layer before the target connection opens.
What does a centralised authentication audit trail contain, and how does it differ from individual application logs?
A centralised authentication audit trail contains a structured log record for every authentication event across all connected systems: actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome. Individual application logs contain authentication events for that application only, in the application’s own log format, requiring manual compilation and format normalisation to produce a consolidated view. A centralised audit trail is queryable across all systems simultaneously, exportable in structured format for regulatory submission, and append-only to prevent post-hoc modification.
How long should authentication event logs be retained to satisfy IRDAI ICS requirements?
The IRDAI ICS Guidelines do not specify a precise retention period in Item 14 itself. Item 35 requires that audit logs be retained for a period defined in the organisation’s IT security policy, sufficient for forensic investigation and regulatory examination. Industry practice at insurance organisations in India typically maintains authentication event logs for a minimum of one year, with privileged session recordings retained for two years or longer depending on the sensitivity of the systems accessed. The retention period should be defined in the IT security policy and consistently applied across all log types.
Can centralised authentication through Akku cover both corporate-owned devices and BYOD devices used by insurance agents and intermediaries?
Yes. Akku’s contextual access controls apply device-based restrictions at the identity layer. Corporate-owned devices enrolled in MDM can be verified as compliant before access is granted. BYOD devices can be permitted for some application access with additional MFA requirements and data transfer restrictions enforced through GPO Manager’s browser-level controls. The centralised authentication layer applies these policies consistently regardless of device type, with every authentication event recorded in the unified audit trail whether the device is corporate-owned or personally owned.
Introduction RBI 2023 Master Direction Clause 19 is the most technically detailed access control provision in the framework. It establishes…
Introduction SEBI CSCRF's Protect function contains the Access Authentication sub-category PR.AA, which runs from PR.AA.S1 through PR.AA.S17 and represents the…
Introduction DPDPA Clause 6 sets specific conditions for consent as a lawful basis for processing personal data. Consent must be…
Introduction Most IT teams at regulated organisations experience compliance audits as events. A notice arrives. A scramble begins. Access records…
Indian companies with EU customers, EU operations, or EU-based employees are subject to the General Data Protection Regulation regardless of…
SOC 2 Type II has become a commercial prerequisite for Indian ITeS and BPO companies serving enterprise clients in North…