Introduction
Multi-factor authentication appears as a requirement in every major compliance framework that applies to Indian organisations. RBI requires it for privileged users accessing critical systems. SEBI CSCRF requires it proportionate to resource sensitivity. IRDAI requires it for network device management and critical system access. ISO 27001:2022 requires secure authentication procedures. SOC 2 requires boundary protection for external access. DPDPA and GDPR require appropriate technical security measures, which regulators and auditors consistently read as including MFA for personal data system access.
The compliance conversation about MFA has matured beyond whether MFA is deployed to whether the deployment satisfies the specific requirement each framework imposes. Most organisations have deployed MFA. The compliance gaps are almost universally in three areas: coverage, proportionality, and evidence.
Coverage gaps exist when MFA is enforced for some access paths but not others. Web-based application login covered, SSH access to the same servers not covered. Customer-facing authentication covered, internal administrator access to production databases not covered. The coverage gap means the MFA deployment satisfies the convenient access paths but misses the high-risk ones.
Proportionality gaps exist when the same MFA method is applied uniformly to all access scenarios regardless of risk. SEBI CSCRF PR.AA.S7 requires authentication commensurate with resource sensitivity. A uniform TOTP deployment applied identically to a document management system and a core banking platform does not satisfy proportionality. Adaptive MFA that escalates the challenge for high-sensitivity access does.
Evidence gaps exist when MFA enforcement operates but the authentication event log does not capture MFA method and outcome per event, or does not cover all access paths. The evidence gap means MFA is enforced in practice but cannot be demonstrated to a compliance auditor.
This blog maps each framework’s MFA requirement to its specific technical standard, identifies the most common deployment gaps, and covers what a compliant MFA implementation must produce as evidence.
MFA Requirements by Framework
RBI 2023 Master Direction
Clause 19(c) requires MFA for privileged users accessing critical information systems. The scope is infrastructure-level: system administrators, database administrators, network engineers, and any role with elevated access to systems classified as critical.
Clause 20(b) requires MFA for all remote access to critical information systems. This extends beyond privileged users to all users accessing critical systems from outside the corporate network.
The most common RBI MFA gap is infrastructure coverage: MFA enforced at the web management console layer but not for direct SSH, database client, and network device CLI access. Clause 19(c)’s critical systems scope covers these access paths, and auditors test them.
SEBI CSCRF
PR.AA.S7 requires authentication controls commensurate with the sensitivity of the resource. This is the proportionality requirement: higher-sensitivity resources require stronger authentication. PR.AA.S9 requires MFA for access to sensitive and critical systems.
The most common SEBI CSCRF MFA gap is uniform deployment: MFA is enforced but the same method and challenge intensity applies to all systems regardless of their classification. PR.AA.S7’s proportionality requirement distinguishes a trading platform from an internal wiki. Adaptive MFA that applies risk-based step-up for higher-sensitivity access satisfies this requirement. Uniform MFA does not.
IRDAI ICS
Item 52 requires MFA for managing network devices and for privileged access to critical systems. Item 64 requires MFA for remote access to organisational systems. Item 65 requires MFA for access to critical applications from outside the corporate network. Item 148 requires step-up authentication for high-sensitivity systems.
The most common IRDAI MFA gap is infrastructure scope: Items 52 and 64 specifically reference network device management and privileged infrastructure access, which are frequently left outside MFA enforcement perimeters.
ISO 27001:2022
A.8.5 requires secure authentication procedures. The control requires that authentication be appropriate to the sensitivity of the information and systems being accessed, and that authentication credentials be protected. The proportionality implication of A.8.5 aligns with SEBI CSCRF PR.AA.S7.
The most common ISO 27001 MFA gap is evidence: MFA is enforced but the authentication event log does not capture MFA method and outcome per event in a structured format that certification auditors can examine.
SOC 2 Type II
CC6.1 requires logical access security software and infrastructure. CC6.6 requires boundary protection against threats from outside the system boundary, which covers MFA for external and remote access. The operating effectiveness requirement means MFA enforcement must be continuous and consistently evidenced throughout the audit period.
The most common SOC 2 MFA gap is operating effectiveness evidence: MFA is deployed but the authentication event log has gaps, coverage inconsistencies, or does not capture events from all access paths throughout the audit period.
DPDPA and GDPR
Clause 8(5) of DPDPA and Article 32 of GDPR both require appropriate security safeguards and appropriate technical measures respectively. Neither explicitly mandates MFA. Both create a general security obligation that regulators and auditors consistently interpret as requiring MFA for systems processing personal data, particularly for privileged access.
The most common gap for DPDPA and GDPR purposes is the absence of MFA for privileged access to databases and servers holding personal data, where a single compromised credential provides unrestricted access to the most sensitive data in the organisation.
The Three Deployment Gaps
Coverage gaps
Coverage gaps are the most prevalent and the most consequential. Every access path to a critical or sensitive system that does not route through MFA enforcement is a coverage gap.
Web-based management console access is typically covered. SSH access to the underlying servers that the consoles manage is typically not. Database client connections using native database protocols are typically not. Network device CLI access via SSH or Telnet is typically not. Kubernetes API access via kubectl is typically not.
These uncovered access paths represent the highest-risk privileged access scenarios in most regulated environments. The web console is a monitored, logged interface. A direct SSH connection to the same server bypasses the console’s audit trail entirely and may not enforce MFA.
Closing coverage gaps requires routing all privileged access to critical systems through a PAM session proxy that enforces MFA at the session layer, before any target system connection opens, regardless of the protocol used. This is the only approach that provides coverage completeness across all privileged access paths.
Proportionality gaps
Proportionality gaps exist when the authentication challenge does not scale with resource sensitivity. A user accessing a document management system and a user accessing a core banking platform face the same TOTP challenge. The platforms have vastly different risk profiles, but the authentication assurance is identical.
Frameworks requiring proportionate authentication, specifically SEBI CSCRF PR.AA.S7 and IRDAI Item 148, require that the authentication model distinguish between sensitivity levels. Adaptive MFA satisfies this by evaluating risk signals at each authentication event and escalating the challenge for higher-risk scenarios: more sensitive systems, unusual access contexts, new devices, or anomalous locations.
The practical implementation is not simply applying different MFA methods to different system tiers. It is deploying an authentication layer that evaluates context at each event and applies a proportionate challenge dynamically, covering both the system sensitivity and the access context simultaneously.
Evidence gaps
Evidence gaps exist when MFA enforcement operates but the audit trail does not capture the required information for every event. Specifically: MFA method not recorded in the authentication event log, MFA outcome not recorded per event, authentication events from some access paths not captured in the centralised log, or log retention insufficient to cover the examination period.
For RBI IS audits, auditors request authentication logs and verify that privileged sessions to critical systems were preceded by successful MFA events. If the log does not capture MFA method and outcome per session, the auditor cannot verify MFA enforcement from the log.
For SOC 2 Type II, auditors sample authentication events from across the audit period. If the log has gaps for some access paths or some time periods, the sample will find events with no corresponding MFA record.
The evidence requirement means the authentication event log must capture: actor identity, timestamp, target system or application, MFA method used, MFA outcome, source IP, device identifier, and geographic location, for every authentication event, across every covered access path, continuously throughout the compliance period.
What a Compliant MFA Implementation Produces
A compliant MFA implementation produces three outputs: enforcement coverage, proportionate challenge behaviour, and structured evidence.
Enforcement coverage
All authentication events to critical and sensitive systems route through the MFA enforcement layer, regardless of the protocol used. SSH access, database connections, RDP sessions, Kubernetes API calls, and web application logins all require MFA at the session proxy layer before the target connection opens. No access path to a covered system bypasses the MFA requirement.
Proportionate challenge behaviour
The authentication challenge scales with the risk profile of the access scenario. High-sensitivity systems require stronger second factors or multi-step challenges. Unusual access contexts, new locations, unrecognised devices, or anomalous timing trigger step-up challenges regardless of the system being accessed. Familiar, low-risk access contexts receive the appropriate challenge without unnecessary friction.
Structured evidence
Every authentication event produces a structured log record with all required fields. The record is generated at the time of the authentication event, stored in append-only format, retained for the compliance period, and exportable in structured format for regulatory examination. The log covers all access paths, all systems, and the complete compliance period with no gaps.
Akku’s Adaptive MFA implements all three outputs. Coverage is achieved through the centralised authentication layer that all connected applications route through and through PAM-layer enforcement for infrastructure access. Proportionality is achieved through AI-powered anomaly detection that evaluates risk signals and escalates challenges accordingly. Evidence is produced by the centralised authentication event log that captures all required fields for every event in append-only, exportable format.
Diagnostic Questions
Does your MFA deployment cover direct SSH access to production servers, direct database client connections, and network device CLI access, or only web-based management console authentication?
For your highest-sensitivity systems, specifically core banking platforms, payment infrastructure, and personal data databases, does MFA apply a stronger challenge than for lower-sensitivity internal applications, or is the same method applied uniformly?
Does your authentication event log capture MFA method and outcome per event for every authentication attempt across every covered access path, or are some access paths not reflected in the centralised log?
For any 30-day window chosen at random from the last 12 months, can you produce a structured export of all authentication events showing MFA method and outcome for every event, without manual compilation from individual application logs?
Has your organisation tested MFA coverage by attempting to connect to critical systems using direct protocol access without routing through the centralised MFA enforcement layer, to verify that no access paths bypass the requirement?
CTAs
See how Akku’s Adaptive MFA addresses compliance requirements across RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, DPDPA, and GDPR with coverage, proportionality, and structured evidence.
Book a conversation with the Akku team to assess your current MFA deployment against the specific requirements of the frameworks that apply to your organisation.
FAQs
Why do compliance frameworks require MFA specifically, and what risk does it address?
MFA addresses credential compromise, the most common initial access vector in security incidents. A single compromised password provides unrestricted access to any system the account is entitled to reach. Adding a second factor means that compromised credentials alone are insufficient for access: the attacker also needs the second factor, which requires either physical possession of the user’s device or a separate attack to obtain. For regulated organisations where a single compromised administrator credential could provide access to core banking systems, customer databases, or payment infrastructure, the risk reduction from MFA enforcement is directly proportionate to the access privilege of the protected accounts.
What is the difference between standard MFA and adaptive MFA for compliance purposes?
Standard MFA applies the same second-factor challenge to every authentication event regardless of context. Adaptive MFA evaluates risk signals at each authentication event and escalates the challenge when signals indicate elevated risk. For compliance frameworks that require proportionate authentication, specifically SEBI CSCRF PR.AA.S7 and IRDAI Item 148, standard MFA does not satisfy the proportionality requirement. Adaptive MFA satisfies it by applying stronger challenges to higher-risk access scenarios. For frameworks with a simpler MFA requirement such as RBI Clause 19(c), both standard and adaptive MFA satisfy the requirement, though adaptive provides stronger security posture.
Does deploying MFA for customer-facing applications satisfy the privileged user MFA requirements in RBI and IRDAI?
No. Customer-facing MFA covers authentication for customers accessing their accounts through internet banking or insurance portals. RBI Clause 19(c) and IRDAI Items 52 and 64 cover internal privileged user authentication to backend critical systems. These are separate populations, separate access scenarios, and separate technical requirements. Satisfying customer-facing MFA requirements does not satisfy internal privileged user MFA requirements. Organisations must address both independently.
What MFA methods are phishing-resistant, and when should they be required?
Phishing-resistant MFA methods are those that cannot be intercepted or replayed by an attacker who tricks the user into authenticating to a fake service. FIDO2 hardware security keys and platform authenticators using WebAuthn are phishing-resistant because the authentication is cryptographically bound to the legitimate domain. Push notification MFA and SMS OTP are not phishing-resistant because they can be defeated by real-time phishing attacks where the user is tricked into approving or entering the factor on a fake site. For the highest-privilege accounts with access to core banking and payment infrastructure, phishing-resistant methods are increasingly recommended by RBI IS auditors and align with global best practice for privileged account protection.
How should organisations handle MFA for service accounts that cannot complete interactive authentication challenges?
Service accounts used for automated processes cannot complete interactive MFA challenges because they are not operated by a human who can respond to a step-up prompt. For service accounts, MFA alternatives include certificate-based authentication where the service authenticates with a client certificate stored in a secure vault, API keys with short rotation cycles that provide a credential security equivalent, and network-level access controls that restrict service account connections to specific IP ranges and ports. The appropriate approach depends on the protocol the service account uses. Service accounts with privileged access to critical systems should be governed through the same PAM infrastructure as human privileged users, with their credentials managed in AkkuVault and their access sessions logged.
What evidence should organisations retain to demonstrate MFA compliance across multiple frameworks simultaneously?
A single structured authentication event log covering all authentication events with MFA method, outcome, actor identity, timestamp, source IP, device, and geographic location satisfies the MFA evidence requirements of RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, DPDPA, and GDPR simultaneously. The log must be: complete, covering every authentication event across every covered system; continuous, with no gaps during the compliance period; structured, in JSON or CSV format with consistent field naming; append-only, with tamper-evident integrity; and exportable, producible for any time period within the retention window without manual compilation. A single log with these properties serves every framework’s evidence requirement from one source.
