Introduction
RBI-regulated entities have deployed MFA for internet banking customers for years. The compliance conversation about MFA has largely been about customer-facing authentication: OTP for net banking, transaction authentication for fund transfers, and step-up challenges for high-value payments. The privileged user MFA requirement in RBI’s 2023 Master Direction is a different obligation and a different architecture.
RBI Clause 19(c) requires MFA for privileged users accessing critical information systems. Clause 20(b) requires MFA for all remote access to critical information systems. These are internal user requirements, not customer authentication requirements. They apply to system administrators accessing production servers, database administrators connecting to core banking databases, network engineers managing routers and switches, and IT managers accessing infrastructure management consoles.
Most regulated entities that have satisfied customer-facing MFA requirements have a significant gap in privileged user MFA coverage. Application-layer MFA, where a web-based management console presents an MFA challenge before granting access, covers the systems with web-based interfaces. It does not cover direct SSH connections to Linux servers, direct database client connections to production databases, or command-line access to network devices. These are the access paths that carry the highest privilege and produce the lowest MFA coverage rate in most regulated entities.
This blog covers what RBI’s MFA requirements specifically mandate for privileged users, where the infrastructure-layer coverage gap exists, and how PAM-layer MFA enforcement closes it.
The Full Scope of RBI’s MFA Requirements
RBI’s MFA requirements appear across multiple clauses in the 2023 Master Direction. Understanding the full scope prevents organisations from satisfying one clause while leaving others unaddressed.
Clause 19(c): Privileged user MFA
Clause 19(c) requires MFA for privileged users accessing critical information systems. The critical information systems scope includes core banking platforms, payment processing infrastructure, production databases, network infrastructure management interfaces, and any system whose compromise would have a material impact on operations.
The privileged user definition covers system administrators, database administrators, network engineers, application administrators with deployment or configuration access, and any other role with elevated permissions on critical systems. The scope is not limited to named system administrators. Any user whose credentials, if compromised, would provide access to critical system administration functions is a privileged user for Clause 19(c) purposes.
Clause 20(b): Remote access MFA
Clause 20(b) requires MFA for all remote access to critical information systems. Remote access includes any access from outside the corporate network, including VPN connections, direct internet access to management interfaces, and cloud-hosted system access from any network.
The remote access MFA requirement is broader than the privileged user requirement: it applies to all users accessing critical systems remotely, not only privileged users. However, in practice the highest-risk remote access scenario is privileged users administering critical systems from remote locations, making Clause 20(b) and Clause 19(c) closely related in their implementation requirements.
Clause 20(a): Centralised authentication for remote access
Clause 20(a) requires centralised authentication for remote access. All remote sessions to information systems must route through a secure, centralised authentication mechanism. Fragmented remote access through multiple VPN solutions, direct management interface exposure, and inconsistent MFA coverage does not satisfy this requirement.
Akku’s RBI mapping for MFA requirements
Akku’s RBI compliance mapping shows Adaptive MFA addresses Clauses 19(c) and 20(b). The PAM architecture through which MFA is enforced for infrastructure-level access addresses the infrastructure coverage gap that Clauses 19(c) and 20(b) create together.
Where Application-Layer MFA Falls Short
Application-layer MFA covers web-based interfaces where users authenticate through a browser or application login screen. It does not cover direct protocol-level connections to infrastructure systems.
SSH access to Linux servers
SSH access to Linux servers is a direct protocol connection, not a web-based application login. When an administrator opens an SSH terminal to a production server, the connection goes directly to the server’s SSH daemon. There is no web-based MFA challenge in this path. If the regulated entity’s MFA enforcement only covers web-based management consoles, SSH access to the same servers is unprotected by MFA.
SSH access is the highest-volume privileged access path at most regulated entities. Core banking application servers, payment processing platforms, database servers, and API gateway servers are all accessed primarily through SSH for administration, configuration, and maintenance. If SSH access is not covered by MFA enforcement, Clause 19(c)’s privileged user MFA requirement is satisfied only for the fraction of privileged access that uses web interfaces.
Database client connections
Database client connections use database protocols, not HTTP. A DBA connecting to a MySQL or PostgreSQL production database from a database management tool such as DBeaver or MySQL Workbench connects through the database port using database credentials. There is no application-layer MFA challenge in this path.
Production banking databases contain the most sensitive data in a regulated entity’s environment: transaction records, customer account data, and in some cases payment card data. DBA access to these databases is among the highest-risk privileged access scenarios. If MFA is not enforced for direct database connections, the DBA credential is the only authentication factor protecting access to this data.
Network device management interfaces
Network engineers managing routers, switches, and firewalls use CLI connections through SSH or Telnet. Management interfaces for network devices may have web-based consoles, but command-line access through SSH remains common and is not covered by web-based MFA enforcement.
Item 52 of IRDAI ICS and Clause 19(c) of RBI both specifically reference network device management as a privileged access scenario requiring MFA. The regulatory attention to this specific scenario reflects awareness that network device access is commonly left outside MFA coverage.
Infrastructure management consoles
Cloud infrastructure management consoles, hypervisor management interfaces, and storage management platforms may have web-based access that is covered by application-layer MFA. However, these platforms also expose API access and CLI access that may not route through the same MFA enforcement. An organisation that enforces MFA for web console access to its cloud infrastructure management platform may leave API and CLI access to the same infrastructure unprotected.
PAM-Layer MFA Enforcement
Closing the infrastructure MFA coverage gap requires enforcing MFA at the session proxy layer, not at the application login layer. When all privileged connections to critical systems route through a PAM session proxy, MFA can be enforced at the proxy layer before any connection to the target system opens.
How AkkuReka enforces MFA at the session layer
AkkuReka functions as a session proxy between privileged users and target systems. Before AkkuReka opens a connection to a target system, the user must authenticate to Akku IAM with MFA. This authentication happens at the Akku platform layer, not at the target system layer. The target system sees only the session proxy connection, not the user’s direct connection attempt.
This architecture means that MFA enforcement applies to SSH connections, database connections, RDP connections, Kubernetes API connections, and web application sessions alike. The protocol used by the target system is irrelevant: the user must authenticate with MFA at the Akku layer before any connection opens, regardless of whether the target system has a native MFA capability.
Coverage across all critical system types
For SSH servers, the workflow is: user authenticates to Akku IAM with MFA, Akku evaluates access policy, session is approved, AkkuReka opens an SSH proxy connection to the target server, AkkuArka injects an ephemeral credential at the protocol layer. The user’s SSH terminal connects through the proxy, not directly to the server. MFA was enforced at step one. The server’s SSH daemon receives a proxy connection, not a direct user connection.
For database servers, the same workflow applies with MySQL or PostgreSQL as the target protocol. For RDP connections to Windows servers, AkkuReka proxies the RDP connection after MFA authentication at the Akku layer. For Kubernetes clusters, kubectl operations route through AkkuReka after MFA authentication.
Adaptive MFA for proportionate enforcement
Akku’s Adaptive MFA evaluates risk signals at each authentication event. Access from a new location, an unrecognised device, or outside normal hours triggers step-up authentication: a more demanding second factor or re-authentication within the session. Access from a familiar location, a compliant corporate device, during normal hours may require a standard second factor.
This proportionate enforcement is what Clause 19(c) implies: authentication controls commensurate with the sensitivity of the resource. A system administrator accessing a development server from their corporate device during normal hours faces a different risk profile than the same administrator accessing a production core banking server from a new country. Adaptive MFA applies the appropriate challenge for each scenario.
MFA Evidence for RBI IS Audit Examination
RBI IS auditors examining Clause 19(c) and 20(b) compliance test both the coverage and the evidence of MFA enforcement for privileged access.
Coverage testing
Auditors attempt to identify access paths that bypass MFA. They examine whether SSH access to critical servers requires MFA at the session level or only at a web console layer. They test direct database connections to assess whether MFA is enforced for non-web protocol access. They review the architecture documentation to identify any privileged access paths that do not route through the centralised MFA enforcement layer.
An organisation that has deployed web console MFA but left SSH and direct database access unprotected will have these gaps identified during coverage testing.
Evidence of continuous enforcement
Auditors examine authentication event logs to verify that every privileged session to a critical system was preceded by a successful MFA event. They sample sessions from across the examination period, not only recent sessions. For each sampled session, they verify that the session open event is preceded by a corresponding MFA authentication event in the audit log.
Sessions that opened without a corresponding MFA event in the audit log indicate either a coverage gap where the session bypassed MFA enforcement, or a logging gap where MFA occurred but was not recorded. Both are findings.
MFA method assessment
Auditors may assess the MFA methods deployed for highest-privilege accounts. For core banking system administrators and payment infrastructure administrators, phishing-resistant MFA methods such as FIDO2 hardware keys are increasingly expected for the most sensitive access scenarios. SMS and push notification MFA, while acceptable for standard users, may be scrutinised for accounts with the highest access privileges given their susceptibility to SIM swap and push notification fatigue attacks.
Diagnostic Questions
Does your MFA enforcement cover direct SSH connections to production servers and direct database client connections to production databases, or only web-based management console access?
For every privileged session to a critical system in the last 90 days, is there a corresponding MFA authentication event in the audit log preceding the session open event?
When a system administrator connects to a production server using an SSH terminal client, does MFA enforcement occur at the session proxy layer before the connection opens, or can the connection be established with only a private key?
Does your MFA coverage extend to remote privileged access from any network, including home networks, hotel networks, and mobile data connections, or only to access from within the corporate network?
For your highest-privilege accounts, specifically those with access to core banking systems and payment infrastructure, are you using phishing-resistant MFA methods such as FIDO2, or SMS and push notification methods that are susceptible to targeted attacks?
CTAs
See how Akku’s Adaptive MFA and PAM architecture address RBI Clause 19(c) and 20(b) MFA requirements for privileged user infrastructure access.
Book a conversation with the Akku team to assess your current MFA coverage against RBI’s privileged user MFA obligations.
FAQs
What is the difference between customer-facing MFA for internet banking and the privileged user MFA requirement in RBI Clause 19(c)?
Customer-facing MFA for internet banking covers authentication for retail and corporate customers accessing their accounts through the bank’s internet banking platform. It is governed by RBI’s guidelines on internet banking and payment authentication. Clause 19(c) covers MFA for internal privileged users, specifically system administrators, database administrators, network engineers, and other roles with elevated access to the bank’s critical information systems. The two requirements are separate and must be addressed independently. Satisfying one does not satisfy the other. The architecture for customer-facing MFA, typically OTP delivered to a registered mobile number, is not appropriate for privileged user MFA for infrastructure access.
Does Clause 19(c) require MFA for all privileged sessions or only for the initial session authentication?
Clause 19(c) requires MFA for privileged users accessing critical information systems. The access event is the triggering requirement. For JIT access where every privileged session is a new access event requiring a new approval, MFA is enforced at the authentication step before each session opens. For standing access models where a privileged user authenticates once and maintains an open session, the initial authentication with MFA satisfies the letter of the clause but not the spirit of the event-by-event control standard. RBI IS auditors examining Clause 19(c) in conjunction with Clause 19(a)’s need-based access requirement will look for evidence that MFA is enforced for each access event, not as a one-time authentication to an always-on privileged account.
What MFA methods does RBI Clause 19(c) require for privileged user access?
The RBI 2023 Master Direction does not specify which MFA methods are required for Clause 19(c) compliance. It requires MFA without prescribing specific factors. In practice, IS auditors assess whether the MFA method is appropriate for the risk level. For standard privileged users, TOTP applications such as Google Authenticator, push notification MFA, and hardware tokens are all acceptable. For the highest-privilege accounts with access to core banking systems and payment infrastructure, phishing-resistant methods such as FIDO2 hardware keys are increasingly recommended given the targeted attack risk these accounts face. Organisations should assess the MFA methods deployed for their highest-risk privileged accounts against the current threat landscape.
How does PAM-layer MFA enforcement differ from target system native MFA?
Target system native MFA is configured on each individual system. A Linux server can be configured with PAM-based MFA that challenges users at the SSH login layer. A web management console can be configured with an integrated MFA provider. Target system native MFA requires separate configuration and maintenance for each system and produces separate authentication event logs per system. PAM-layer MFA enforcement, through AkkuReka, applies MFA at the session proxy before any target system connection opens. It requires configuration once at the PAM layer, applies consistently to all target systems regardless of their native MFA capability, and produces a centralised authentication event log covering all target systems. PAM-layer enforcement provides better coverage, simpler maintenance, and more consistent evidence for regulatory examination.
Does Clause 20(b)’s remote access MFA requirement apply to VPN-connected access as well as direct internet access?
Clause 20(b) requires MFA for all remote access to critical information systems. VPN connectivity establishes a network tunnel but does not itself constitute a compliant remote access security control for Clause 20(b) purposes. A user who connects via VPN and then SSH to a production server without MFA has satisfied the network connectivity requirement but not the authentication security requirement. MFA must be enforced for the privileged access event itself, whether the user is on VPN, on a direct internet connection, or on any other network. PAM-layer MFA enforcement through AkkuReka satisfies Clause 20(b) for all remote access paths because MFA is enforced at the session proxy layer regardless of how the user’s network connection is established.
How should regulated entities handle MFA for emergency access scenarios under operational continuity requirements?
Emergency access scenarios where normal authentication mechanisms may be unavailable require a documented emergency access procedure that satisfies the security objective of Clause 19(c) while enabling operational continuity. The emergency procedure should include: a defined list of emergency access scenarios, pre-registered backup MFA factors for privileged users that can be used when primary MFA is unavailable, a break-glass account process with tight controls and mandatory post-incident review, and enhanced session recording for all emergency access sessions. Emergency access must not create a persistent bypass of MFA enforcement. Each emergency access event must be logged with justification and subject to post-incident review. The emergency procedure must be tested periodically to verify it works when needed without being so accessible that it undermines normal MFA enforcement.
