RBI 2023 Master Direction Clause 20 addresses teleworking and remote access security. It is one of the most operationally relevant clauses for regulated entities whose workforce operates in hybrid or distributed modes. The clause establishes four requirements: centralised authentication for remote access under Clause 20(a), MFA for remote access to critical systems under Clause 20(b), session logging for remote access under Clause 20(c), and device compliance verification before remote access is granted under Clause 20(d).
Most regulated entities deployed remote access infrastructure rapidly during the pandemic period and have not fully assessed whether that infrastructure satisfies Clause 20’s technical requirements. VPN connectivity was extended to more staff. Laptop issuance increased. MFA was deployed for internet banking and email access. What many entities did not address systematically is the Clause 20 requirement for centralised authentication covering all remote access paths, device compliance verification before access is granted, and session logging that covers remote access events at the activity level rather than only the connection level.
The distinction between remote access that is operationally functional and remote access that satisfies Clause 20 is the same distinction that runs through the rest of the Master Direction: policy compliance versus technical enforcement. An organisation with a teleworking policy, a VPN deployment, and endpoint security software has the operational infrastructure for remote work. Whether that infrastructure satisfies Clause 20’s centralised authentication, device verification, MFA, and session logging requirements is a separate question.
This blog covers each Clause 20 sub-clause in detail, what it requires technically, the most common implementation gaps, and how IAM controls address each requirement.
Clause 20(a) requires that remote access to information systems be provided through a secure, centralised authentication mechanism. All remote sessions must authenticate through a single identity layer that applies consistent security controls regardless of which system the user is accessing.
Centralised authentication means that every remote access event, whether the user is accessing a business application, an infrastructure management console, or a cloud-hosted service, routes through the same identity provider with the same authentication policy applied. Fragmented remote access infrastructure where different systems have different authentication mechanisms and different MFA enforcement does not satisfy the centralised requirement.
The centralised mechanism must be secure: it must enforce authentication controls appropriate to the sensitivity of the systems being accessed. A centralised VPN that provides network-level access without application-level authentication controls does not constitute a centralised authentication mechanism for Clause 20(a) purposes. The centralised mechanism must sit at the application and session layer, not only at the network layer.
The most common Clause 20(a) gap is the coexistence of centralised authentication for some systems and direct authentication for others. Cloud SaaS applications route through the centralised IdP. Legacy on-premises systems authenticate directly with Active Directory credentials. Infrastructure management interfaces accept direct SSH key authentication without routing through the centralised identity layer. The result is partial centralisation that does not satisfy the complete coverage Clause 20(a) requires.
Akku’s unified cloud identity store and SSO infrastructure provide the centralised authentication mechanism Clause 20(a) requires. All connected applications, cloud SaaS, legacy on-premises systems through directory integration, and custom internal applications through credential replay, authenticate through Akku’s centralised IdP. Infrastructure access routes through AkkuReka’s session proxy, extending centralised authentication to SSH, RDP, database, and Kubernetes access.
The single identity layer means that every remote access event, regardless of the destination system, generates a record in the same centralised authentication event log. This unified logging is both the centralisation evidence and the session logging evidence Clause 20(c) requires.
Clause 20(b) requires MFA for all remote access to critical information systems. The scope covers both end users and privileged users accessing critical systems from outside the corporate network.
MFA must be enforced for every remote access session to a critical information system, not only for sessions flagged as high-risk. The consistent enforcement requirement means that MFA cannot be optional or context-dependent for critical system access from remote locations: every remote session to a critical system must complete MFA before access is granted.
The critical information systems scope under Clause 20(b) follows the same definition as Clause 19(c): systems whose compromise would have a material impact on operations, including core banking platforms, payment processing infrastructure, production databases, and network management interfaces.
For privileged users accessing critical infrastructure remotely, Clause 20(b) and Clause 19(c) overlap: both require MFA for the same access scenarios. The combined requirement means that privileged remote access to critical systems must satisfy both the privileged user MFA standard of Clause 19(c) and the remote access MFA standard of Clause 20(b) simultaneously.
The most common Clause 20(b) gap is inconsistent coverage: MFA is enforced for corporate email and productivity applications but not for remote access to production servers, databases, and network management interfaces. The corporate applications are the ones with web-based logins that were covered when MFA was first deployed. The infrastructure access paths were added to the remote access perimeter without MFA integration.
Akku’s Adaptive MFA enforces authentication for all applications connected to the centralised identity layer. For remote access scenarios, contextual access controls detect that the session originates from outside the corporate network and apply the appropriate challenge. For infrastructure access, PAM-layer MFA enforcement through AkkuReka ensures that every remote SSH, RDP, and database session requires MFA at the IAM layer before the session proxy connection opens.
The consistent coverage across all application and infrastructure access paths is what satisfies Clause 20(b)’s all remote access to critical systems standard.
Clause 20(c) requires that remote access sessions be logged with sufficient detail to enable identification of the user, the systems accessed, and the actions taken. This is a session activity logging requirement, not only a connection logging requirement.
Connection logging records that a remote session was established: user identity, source IP, target system, connection timestamp, and session duration. Action logging records what happened during the session: commands executed for SSH, queries run for database access, screen activity for RDP.
Clause 20(c)’s identify the user, the systems accessed, and the actions taken standard requires all three dimensions. Identifying the user requires the actor identity in the session record. Identifying the systems accessed requires the target system in the session record. Identifying the actions taken requires session activity logging at the command or query level for privileged access.
For standard end users accessing business applications remotely, application-level activity logs within those applications provide the actions taken dimension. For privileged users accessing infrastructure remotely, there is typically no application-level activity log for direct system connections. SMARTAudit Trails are the control that satisfies the actions taken requirement for remote privileged sessions.
The most common Clause 20(c) gap is the distinction between connection logs and activity logs. VPN logs record that a user connected remotely. Authentication logs record that a user authenticated to a specific application. Neither records what the user did after authentication. For remote privileged sessions to infrastructure systems, the actions taken dimension requires session-level recording.
Akku’s centralised authentication event log satisfies the user identity and systems accessed dimensions for all remote access events. SMARTAudit Trails satisfy the actions taken dimension for remote privileged sessions: SSH keystroke logs, SQL query capture for database sessions, and RDP screen recordings are captured at the protocol layer by AkkuReka regardless of whether the session originated locally or remotely.
The remote access origin is captured in the authentication event record through the source IP and geographic location fields. A remote session produces the same structured, complete session record as a local session, with the remote origin visible in the session metadata.
Clause 20(d) requires that remote access be restricted to authorised devices and that device compliance be verified before access is granted. The device verification must be technical, not policy-based: the access control must verify the device’s compliance state and block access from non-compliant or unregistered devices.
Device compliance verification requires integration between the identity layer and the device management layer. When a user attempts remote access, the authentication system must query the device management platform to verify the device’s current compliance state: Is it enrolled in MDM? Is it running an approved operating system version? Is it encrypted? Has it checked in with the MDM platform recently? Only after compliance verification should access proceed.
For corporate-owned devices, enrollment in MDM and compliance with the device policy are the baseline requirements. For BYOD environments, device compliance verification must assess whether the personal device meets the minimum security requirements for remote access to corporate systems.
The verification must occur at each access attempt, not only at enrollment. A device that was compliant at enrollment may have fallen out of compliance through OS updates that break policy, antivirus deactivation, or MDM check-in failures. The at-access verification catches compliance drift that enrollment-time verification misses.
The most common Clause 20(d) gap is certificate-based device verification that checks enrollment but not current compliance state. A device is issued a client certificate at enrollment. The certificate is presented at remote access to confirm the device is enrolled. But the certificate does not reflect the device’s current compliance state: an enrolled device that has not checked in with MDM for 60 days and is running outdated software still presents a valid certificate.
Real compliance verification queries the MDM platform in real time to assess the device’s current state, not only its enrollment status.
Akku’s contextual access controls integrate device compliance verification at the authentication layer. Device-based access restrictions query MDM enrollment and compliance status before access is granted. A device that is not enrolled in Akku MDM or that has failed compliance checks is blocked from accessing in-scope applications regardless of whether the user’s credentials are valid.
MDM device compliance policies cover OS version, encryption status, passcode requirements, MDM check-in recency, and app compliance. A device that fails any configured compliance criterion is flagged non-compliant and blocked from remote access until compliance is restored.
The device compliance check result is logged alongside the authentication event, creating a record showing that compliance verification occurred and what the result was for each remote access attempt. This log is the Clause 20(d) evidence.
Akku’s RBI compliance mapping shows Mobile Device Manager addresses Clauses 20(c), 20(d), 23(d), and 25(b), and GPO Manager addresses the same clauses across the endpoint security layer.
Satisfying all four Clause 20 sub-clauses requires the four controls to operate as an integrated system, not as separate deployments.
Centralised authentication under Clause 20(a) provides the single identity layer that all remote access routes through. MFA under Clause 20(b) enforces authentication assurance at that identity layer for all remote access to critical systems. Session logging under Clause 20(c) captures the complete remote session record, from authentication through to session activity, in the centralised audit trail. Device compliance verification under Clause 20(d) gates access at the identity layer based on real-time device compliance status from MDM.
When these four controls operate together through a single platform, the remote access session produces a complete, structured record: device compliance verified, MFA completed, session authenticated, session activity recorded. This is the evidence chain that an RBI IS audit of Clause 20 expects to find for every remote session to a critical system.
Does every remote access session to a critical information system route through a centralised identity provider that applies consistent authentication controls, or do some systems accept direct authentication bypassing the centralised layer?
For remote access sessions by privileged users to production servers and databases, is there a session activity recording capturing commands executed and queries run, not only a VPN or authentication log confirming the connection?
Does your device compliance verification assess the device’s current compliance state in real time at each access attempt, or does it verify only that the device is enrolled based on a certificate issued at enrollment time?
Can you produce for any remote access session to a critical system in the last 90 days: the device compliance verification result, the MFA authentication record, the session activity log, and the source network context, all from a single queryable audit trail?
Have you tested whether remote access to critical infrastructure systems, specifically SSH and direct database connections, requires MFA enforcement, or whether these access paths can be established from remote networks without the centralised MFA challenge?
See how Akku addresses RBI Clause 20 teleworking and remote access requirements across centralised authentication, MFA enforcement, session logging, and device compliance verification.
Book a conversation with the Akku team to assess your current remote access infrastructure against RBI Clause 20’s technical obligations.
Does RBI Clause 20 apply only to employees working from home, or to all remote access scenarios?
Clause 20 covers all remote access to information systems, not only work-from-home scenarios. Remote access includes any access from outside the corporate network: employees working from home, staff travelling and accessing systems from hotels or airports, third-party vendors accessing systems remotely for support or maintenance, and any other access that originates outside the corporate network perimeter. The clause is technology-neutral: it applies regardless of whether remote access is through VPN, direct internet access to cloud-hosted systems, or any other remote connectivity method.
What is the difference between VPN-based remote access and the centralised authentication Clause 20(a) requires?
VPN provides network-level connectivity: it extends the corporate network to the remote device, allowing the device to reach systems on the corporate network. VPN does not provide application-level authentication controls. A user on VPN can still authenticate to individual applications using direct credentials, bypassing any centralised identity provider. Clause 20(a) requires centralised authentication at the application and session layer, not only network-level connectivity. VPN may be a component of the remote access architecture, but it does not substitute for centralised authentication. The centralised identity provider must sit between the remote user and every application or system they access, regardless of whether VPN connectivity is also used.
Does Clause 20(b) require MFA for video conferencing and productivity tools accessed remotely, or only for critical information systems?
Clause 20(b) requires MFA specifically for remote access to critical information systems. The critical information systems definition covers systems whose compromise would have a material impact on operations: core banking platforms, payment processing systems, production databases, and network management infrastructure. Standard productivity tools including email, video conferencing, and document management are not typically classified as critical information systems for Clause 20(b) purposes unless they hold regulated data or are critical to operational continuity. However, MFA for all corporate applications is a security best practice that most regulated entities implement regardless of the specific Clause 20(b) scope.
How does Clause 20(d)’s device compliance requirement apply to BYOD environments where employees use personal devices for remote work?
For BYOD remote access, Clause 20(d) requires that device compliance be verified before access is granted. For personal devices, the compliance baseline must be appropriate to the device type: OS version currency, passcode enforcement, encryption, and MDM enrollment or at minimum a managed work profile on Android devices. Access from personal devices to systems classified as critical should be treated with heightened scrutiny: either requiring higher assurance device compliance or restricting access to a limited subset of functionality through a secure browser with no data download capability. The compliance verification infrastructure must extend to personal devices: a device compliance policy that applies only to corporate-owned devices does not satisfy Clause 20(d) for BYOD environments.
Can a regulated entity satisfy Clause 20 using a cloud-based identity provider, or does the centralised authentication mechanism need to be on-premises?
Clause 20 does not require on-premises deployment of the centralised authentication mechanism. A cloud-based identity provider that routes all remote access authentication through a centralised platform satisfies Clause 20(a)’s centralised mechanism requirement. The RBI framework is technology-neutral on deployment model. The relevant assessment is whether the cloud-based platform provides the required controls: consistent authentication enforcement, MFA, session logging, and device compliance verification. Akku supports both cloud-native SaaS deployment and on-premises deployment for regulated entities with specific data sovereignty or private network requirements.
How does Clause 20’s teleworking security requirement interact with Clause 19’s privileged access requirements for remote privileged sessions?
Clauses 19 and 20 overlap for remote privileged access scenarios. A system administrator accessing a production server from home must satisfy Clause 19(a)’s need-based access requirement, Clause 19(b)’s supervision and logging requirement, Clause 19(c)’s MFA requirement, and Clause 20(a)’s centralised authentication requirement, Clause 20(b)’s remote MFA requirement, Clause 20(c)’s remote session logging requirement, and Clause 20(d)’s device compliance requirement simultaneously. The PAM architecture addresses both clause sets in a single implementation: JIT access satisfies 19(a), SMARTAudit Trails satisfy 19(b) and 20(c), PAM-layer MFA satisfies 19(c) and 20(b), centralised authentication through Akku IdP satisfies 20(a), and MDM device compliance verification satisfies 20(d)
Introduction Indian ITeS companies processing US healthcare data on behalf of US covered entities are business associates under HIPAA. The…
Introduction DPDPA Clause 8(4) requires Data Fiduciaries to implement appropriate technical and organisational measures to ensure effective observance of the…
Introduction SOC 2 Trust Services Criteria CC7.2 requires that the entity monitors system components and the operation of those components…
Introduction RBI-regulated entities have deployed MFA for internet banking customers for years. The compliance conversation about MFA has largely been…
Introduction SEBI CSCRF PR.AA.S1(G1g) and PR.AA.S1(G1h) require that user accounts inactive beyond a defined threshold be automatically disabled and that…
Introduction ISO 27001:2022 Annex A.8.2 requires that the allocation and use of privileged access rights be restricted, controlled, and reviewed.…