Introduction
Zero trust is not a product category. It is an access architecture built on three principles: verify every identity before granting access, enforce least privilege for every access decision, and monitor continuously for anomalies. What makes zero trust relevant to compliance is that every major regulatory framework reviewed in this series, DPDPA, RBI, SEBI CSCRF, IRDAI ICS, ISO 27001:2022, SOC 2 Type II, and GDPR, has arrived at requirements that collectively describe zero trust architecture without using the term.
RBI Clause 19(a) requires need-based access. That is least privilege. RBI Clause 19(c) requires MFA for privileged users. That is verify every identity. RBI Clause 15 requires audit trails for every session. That is monitor continuously. SEBI CSCRF PR.AA.S7 requires authentication controls commensurate with resource sensitivity. That is risk-based verification. ISO 27001:2022 A.8.2 requires that privileged access be event-by-event and time-limited. That is JIT access with no standing privilege. DPDPA Clause 8(4) requires that access be limited to authorised purposes. That is least privilege at the data processing layer.
The convergence is not accidental. Regulators across industries and jurisdictions have independently arrived at the same access architecture requirements because the threat model they are responding to is the same: credential compromise, insider access abuse, and entitlement drift are the dominant vectors in the breaches and incidents that drive regulatory action. Zero trust architecture addresses all three.
This blog maps the zero trust principles to the specific regulatory requirements that implement them, explains why compliance frameworks are converging on this architecture, and covers what implementing zero trust means technically for regulated organisations.
Verify Every Identity: How Regulations Implement This Principle
Zero trust’s verify every identity principle requires that every access request be authenticated with assurance proportionate to the sensitivity of the resource, regardless of where the request originates. The implicit trust of the corporate network, where users inside the perimeter were trusted by default, is replaced by explicit verification for every request.
How the frameworks state it
RBI 2023 Master Direction Clause 19(c) requires MFA for privileged users accessing critical information systems. Clause 20(b) requires MFA for all remote access to critical systems. SEBI CSCRF PR.AA.S7 requires authentication controls commensurate with the sensitivity of the resource. IRDAI ICS Items 52 and 64 require MFA for network device management and critical system access. ISO 27001:2022 A.8.5 requires secure authentication procedures. SOC 2 CC6.1 and CC6.6 require logical access security software and boundary protection. GDPR Article 32(1)(b) and DPDPA Clause 8(5) require appropriate security measures for processing.
What this requires technically
Verify every identity requires adaptive, risk-based authentication that evaluates context at each access event. Device posture, geographic location, IP reputation, time of day, and behavioural baseline are the signals that determine authentication assurance at the point of access. A user accessing from a recognised, compliant device at a normal time from a known location faces a standard authentication challenge. The same user accessing from an unrecognised device, a new country, or at an unusual hour faces an escalated challenge.
This proportionate model is what SEBI CSCRF PR.AA.S7 requires. A uniform MFA enforcement applied identically to all sessions regardless of risk context does not satisfy the proportionality requirement. Adaptive MFA that escalates based on risk signals does.
For infrastructure access specifically, MFA must extend to the protocol layer. SSH sessions to servers, database management connections, and network device management interfaces must be authenticated with the same assurance as application-layer access. The infrastructure layer is where most regulated entities have an MFA coverage gap.
Akku’s Adaptive MFA implements risk-based authentication across all connected applications, with infrastructure-level MFA enforcement through PAM for privileged access scenarios.
Enforce Least Privilege: How Regulations Implement This Principle
Zero trust’s enforce least privilege principle requires that every user, service, and system has access only to what they need for their current, specific task, and that access is removed when the task is complete.
How the frameworks state it
RBI Clause 19(a) requires need-based access: users access only what their role requires. SEBI CSCRF PR.AA.S1 through S9 cover identity management, access provisioning, and least privilege enforcement. IRDAI ICS Item 50 requires access restricted to authorised personnel on a need-to-know basis. ISO 27001:2022 A.5.15 covers access control and A.8.2 requires privileged access to be event-by-event and time-limited. SOC 2 CC6.2 and CC6.3 require formal user registration and access modification based on the system of record for entitlements. DPDPA Clause 8(4) requires that processing be limited to authorised purposes. GDPR Article 25(2) requires data minimisation by default.
What this requires technically
Least privilege at the identity layer requires three controls operating together. Role-based access control that scopes access entitlements to what each role legitimately requires. SoD enforcement that prevents conflicting role combinations from accumulating in a single user. Periodic access reviews that detect and revoke entitlements that are no longer appropriate.
Least privilege for privileged access requires JIT access. No administrator holds standing credentials to servers, databases, or network devices. Access is granted for the duration of an approved, time-bound session and automatically revoked on expiry. This is what ISO 27001 A.8.2’s event-by-event, need-to-use requirement describes. It is also what RBI Clause 19(a)’s need-to-do access framing requires for infrastructure access.
AkkuArka’s per-session ephemeral credentials implement least privilege at the credential layer. Each session uses a unique credential scoped to the access level required for that session’s approved purpose. The credential cannot be reused after the session closes. This is not credential rotation. It is per-session credential lifecycle management that makes standing privilege architecturally impossible.
Contextual access controls add a further least-privilege layer by restricting access based on device compliance, IP range, geographic location, and time of day. An entitlement that is valid for a user’s role may still be blocked if the access context does not satisfy the contextual policy. This is the granular access control that frameworks like SEBI CSCRF PR.AA.S4 and RBI Clause 20 require for remote and distributed workforce access.
Monitor Continuously: How Regulations Implement This Principle
Zero trust’s monitor continuously principle requires that all access activity be logged, that anomalies be detected as they occur rather than discovered in retrospective log review, and that the audit trail be available for investigation at any time.
How the frameworks state it
RBI Clause 15 requires audit trails suitable for forensic investigation and dispute resolution. SEBI CSCRF DE.CM.S1 through S3 require continuous monitoring of system components with automated anomaly detection. IRDAI ICS Item 5 requires user behaviour monitoring to detect anomalies in login time, location, and session duration. ISO 27001:2022 A.8.15 requires logging of user activities and A.8.16 requires monitoring for anomalous behaviour. SOC 2 CC7.2 requires monitoring of system components for anomalies. GDPR Article 32(1)(d) requires regular testing and evaluation of technical security measures.
What this requires technically
Continuous monitoring requires three layers. Authentication event monitoring that detects anomalies at the login layer: MFA failure spikes, geographic anomalies, access outside defined time windows, and new device registrations. Session activity monitoring for privileged access through SMARTAudit Trails: every command, every query, every screen action captured at the protocol layer. Access governance monitoring through the IGA layer: entitlement drift detection through access reviews, SoD violation detection through the rules engine, and dormant account identification through activity monitoring.
The monitoring infrastructure must be active, not passive. Logs that are stored and reviewed periodically do not satisfy DE.CM’s continuous monitoring requirement or A.8.16’s anomaly detection requirement. The monitoring layer must evaluate events against baselines as they occur and generate alerts without waiting for a review cycle.
The audit trail must be tamper-evident and available on demand. SEBI CSCRF GV.OC.S2(G3) requires on-demand log access for SEBI examination. RBI Clause 15(c) requires tamper-protected logs. IRDAI Item 274 requires on-demand evidence production for regulatory examination. An append-only audit log with structured export capability satisfies all three simultaneously.
Why Compliance Frameworks Converge on Zero Trust Architecture
The convergence of compliance frameworks on zero trust architecture reflects the shared threat model that has driven regulatory action across industries and jurisdictions over the last decade.
The shared threat model
The incidents that drive regulatory action have consistent characteristics. Credential compromise through phishing or credential stuffing gives an attacker authenticated access with no visible breach of the perimeter. Insider access abuse exploits legitimate entitlements to access data or systems beyond what the role requires. Entitlement drift creates attack surface as users accumulate access across role changes without systematic revocation. Standing privileged credentials provide persistent access that, once compromised, cannot be revoked without disabling the account entirely.
Zero trust architecture addresses all four vectors: adaptive MFA raises the bar for credential compromise. Least privilege limits the blast radius of insider access abuse. Access reviews detect and remediate entitlement drift. JIT access and per-session ephemeral credentials eliminate standing privilege.
When regulators across different sectors, the RBI, SEBI, IRDAI, ISO, AICPA, and EU data protection authorities, independently arrive at requirements for MFA, least privilege, session monitoring, and access reviews, they are each responding to the same incident patterns in their respective regulated sectors. The technical architecture that addresses those incident patterns is zero trust.
What convergence means for regulated organisations
For organisations subject to multiple compliance frameworks, the convergence on zero trust architecture is a practical efficiency. Implementing zero trust principles satisfies the access control requirements of multiple frameworks simultaneously because the frameworks are describing the same technical architecture in different regulatory language.
An adaptive MFA deployment that satisfies RBI Clause 19(c) simultaneously satisfies SEBI CSCRF PR.AA.S7, IRDAI ICS Items 52 and 64, and ISO 27001 A.8.5. A JIT access implementation that satisfies ISO 27001 A.8.2 simultaneously satisfies RBI Clause 19(a) and SOC 2 CC6.3. A continuous monitoring infrastructure that satisfies SEBI CSCRF DE.CM simultaneously satisfies ISO 27001 A.8.16 and SOC 2 CC7.2.
The efficiency is real and measurable. Akku’s compliance mapping shows 15 DORA articles fully addressed, 41 ISO 27001 clauses mapped, 88 SEBI CSCRF compliance items covered, 79 IRDAI requirements addressed, and 36 GDPR compliance items supported, from a single platform implementing the same zero trust architecture across all frameworks.
The Zero Trust Implementation Stack for Regulated Organisations
Implementing zero trust architecture for a regulated organisation requires five technical capabilities operating together.
Centralised identity and authentication infrastructure with adaptive MFA covering all applications and infrastructure access paths. This is the verify every identity layer. Akku’s unified cloud identity store, SSO, and Adaptive MFA constitute this layer.
Role-based and attribute-based access control with SoD enforcement and contextual access restrictions. This is the enforce least privilege layer for standard access. Akku’s RBAC, ABAC, contextual access controls, and IGA SoD rules engine constitute this layer.
JIT access with per-session ephemeral credentials for privileged infrastructure access. This is the enforce least privilege layer for privileged access. AkkuArka and AkkuReka’s PAM architecture constitute this layer.
Continuous monitoring with anomaly detection at the authentication layer and session activity logging at the privileged access layer. This is the monitor continuously layer. Akku’s Adaptive MFA anomaly detection, SMARTAudit Trails, and identity and access security monitoring constitute this layer.
Automated lifecycle management with access reviews and dormant account controls. This is the continuous access governance layer. Akku’s User Lifecycle Manager, IGA access review campaigns, and automated deprovisioning constitute this layer.
Diagnostic Questions
Does your authentication infrastructure apply risk-based verification for every access request, escalating the challenge based on device posture, location, and behavioural signals, or does it apply uniform MFA regardless of access context?
Do privileged users hold standing credentials to servers and databases that are valid between sessions, or does your architecture ensure that access to critical infrastructure requires a new approval and uses a session-specific credential for every connection?
Does your monitoring infrastructure detect authentication anomalies in real time and generate alerts, or are anomalies discovered during periodic log review after the fact?
Can you produce evidence that access entitlements across all connected systems are periodically reviewed and that entitlements no longer appropriate are revoked, with a structured evidence record for every review cycle?
If a privileged user’s credentials were compromised today, how many systems would the attacker be able to access, and for how long, before the access was detected and revoked?
CTAs
See how Akku implements zero trust access architecture across identity assurance, least privilege enforcement, and continuous monitoring for regulated organisations.
Book a conversation with the Akku team to assess your current access architecture against zero trust principles and the compliance frameworks that require them.
FAQs
What is zero trust architecture, and how does it differ from perimeter-based security?
Perimeter-based security assumes that users inside the corporate network are trusted and that the security boundary is the network edge. Zero trust replaces implicit trust with explicit verification: every access request is authenticated with appropriate assurance, every access decision enforces least privilege, and every session is monitored continuously, regardless of where the request originates. The shift from perimeter to zero trust is driven by the dissolution of the network perimeter through remote work, cloud adoption, and mobile access, combined with the demonstrated failure of perimeter-based models to prevent credential compromise and insider access abuse.
Why are compliance frameworks converging on zero trust architecture if they were written independently?
The convergence reflects the shared incident patterns that drove regulatory action across sectors. Credential compromise, insider access abuse, entitlement drift, and standing privileged credentials are the dominant vectors in the breaches and incidents that regulators in financial services, insurance, data protection, and IT assurance have all observed in their respective regulated populations. The technical architecture that addresses these vectors, verify every identity, enforce least privilege, and monitor continuously, is zero trust. When regulators independently arrive at requirements for MFA, need-based access, session recording, and access reviews, they are each describing the same architecture in their own regulatory language.
Does implementing zero trust architecture require replacing existing IAM infrastructure?
Not necessarily. Zero trust is an architecture achieved through the combination of controls, not a single product replacement. An organisation can extend its existing infrastructure toward zero trust principles by adding adaptive MFA where standard MFA exists, implementing JIT access for privileged users without replacing existing identity infrastructure, adding session activity logging for privileged sessions through a PAM-layer proxy, and implementing automated access reviews through an IGA platform. The transition to zero trust architecture is typically incremental, prioritising the highest-risk access scenarios first.
How does JIT access implement zero trust’s least privilege principle for privileged users?
JIT access means that privileged users hold no standing credentials to target systems. Every privileged session requires a formal approval, uses a session-specific credential generated at approval and revoked at close, and operates within a defined time window. This implements least privilege at three levels simultaneously: the user has no access between sessions, the credential for each session is scoped to the approved purpose, and the session window limits the duration of elevated access. Standing privilege with persistent credentials is the antithesis of zero trust’s least privilege principle. JIT access operationalises the principle for every privileged session.
How does continuous monitoring satisfy the zero trust principle of assume breach?
The assume breach principle in zero trust holds that the network should be monitored as if a breach has already occurred or is imminent. This requires that all activity, not only suspicious activity, be logged and that anomalies be detected and acted upon in real time. Continuous monitoring through authentication event logging, session activity recording, and anomaly detection implements this principle technically. When an anomaly is detected, such as a privileged user accessing an unusual system or executing commands outside their normal pattern, the monitoring infrastructure surfaces it for investigation rather than waiting for an incident report. The audit trail produced by continuous monitoring also satisfies the forensic investigation requirements that RBI Clause 15, SEBI CSCRF PR.AA.S12, and ISO 27001 A.8.15 impose.
Can a single IAM deployment implement zero trust architecture across multiple compliance frameworks simultaneously?
Yes. Zero trust architecture is implemented through the combination of adaptive MFA, RBAC with least privilege enforcement, JIT access with per-session ephemeral credentials, continuous monitoring with anomaly detection, and automated lifecycle management with access reviews. These controls, implemented in a single IAM platform, satisfy the verify every identity, enforce least privilege, and monitor continuously principles simultaneously. Because compliance frameworks have converged on requirements that collectively describe this architecture, a single deployment implementing zero trust principles produces compliance evidence for DPDPA, RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, and GDPR from the same technical foundation.
