The Securities and Exchange Board of India’s Cybersecurity and Cyber Resilience Framework applies to all SEBI-regulated entities: stock brokers, depository participants, asset management companies, portfolio managers, investment advisers, registrars and transfer agents, and market infrastructure institutions. It is one of the most technically detailed cybersecurity frameworks issued by any Indian regulator, with 232 guidelines in Part II covering identity management, access controls, privileged access, audit logging, monitoring, and incident response.
SEBI CSCRF is structured around six functions drawn from the NIST Cybersecurity Framework: Govern, Identify, Protect, Detect, Respond, and Evolve. The Protect function, specifically the Access Authentication sub-category PR.AA, carries the largest concentration of IAM-relevant requirements. The Detect function under DE.CM and the Govern function under GV.OC add audit logging, monitoring, and on-demand log access requirements that many entities are not currently meeting.
The framework differentiates between entity tiers. Market Infrastructure Institutions, Qualified REs, and Mid-size REs face progressively higher requirements. This blog covers the requirements that apply across entity types, with specific clause references drawn from the SEBI CSCRF Part II guidelines and Akku’s SEBI compliance mapping documentation, which covers 88 unique compliance items with 145 total clause mappings across the platform.
CSCRF Framework Structure and Applicability
Understanding how SEBI CSCRF is structured is necessary before mapping individual requirements to technical controls. The framework’s six-function structure determines where each requirement sits and how audit evidence is organised.
Framework structure
The six functions are Govern (GV), Identify (ID), Protect (PR), Detect (DE), Respond (RS), and Evolve (EV). Each function contains sub-categories, and each sub-category contains specific guidelines at multiple tiers.
The Protect function contains the Access Authentication sub-category (PR.AA), which runs from PR.AA.S1 through PR.AA.S17 and covers identity management, credential management, access provisioning, MFA, privileged access, remote access, and external user access. This single sub-category accounts for a large proportion of the IAM-relevant requirements in the framework.
The Govern function contains the Organisational Context sub-category (GV.OC) and the Policy sub-category (GV.PO), which include requirements for on-demand log access and domain-specific security policy enforcement. The Detect function contains the Continuous Monitoring sub-category (DE.CM), which requires continuous monitoring of authentication events and access patterns.
Tiered applicability
Market Infrastructure Institutions face the highest tier requirements across all six functions. Qualified REs, defined by trading volume, assets under management, or number of clients above defined thresholds, face enhanced requirements in several sub-categories. Mid-size and Small REs face the baseline requirements. The specific tier an entity falls into determines which guideline levels within each sub-category apply.
Identity and Access Management Requirements Under PR.AA
PR.AA is the access authentication sub-category and contains the most detailed IAM requirements in the framework. It covers identity management, access provisioning, credential management, MFA, and access control policy enforcement.
What the framework requires
PR.AA.S1 requires that all users be uniquely identified and that identity be managed through a centralised system. Shared accounts and generic credentials are explicitly inconsistent with this requirement. Akku’s SEBI mapping shows Cloud Directory addresses PR.AA.S1 and several related guidelines.
PR.AA.S6 requires strong credential management including password policies, credential storage security, and credential lifecycle management. Akku’s mapping shows Password Manager addresses PR.AA.S6 across eight guideline mappings.
PR.AA.S4 and PR.AA.S5 require access control based on the principle of least privilege, with access provisioned only to the extent required for the user’s current role and function. Access Manager addresses PR.AA.S4 and PR.AA.S5 across 13 guideline mappings, the highest single-module count after GPO Manager and Audit Logs.
PR.AA.S7 requires that authentication controls be commensurate with the sensitivity of the resource being accessed. This is the proportionate, risk-based authentication requirement that Adaptive MFA is specifically designed to satisfy. Akku’s mapping shows Adaptive MFA addresses PR.AA.S7 and 10 additional guideline references across the PR.AA sub-category.
PR.AA.S15 requires endpoint security controls to ensure that only compliant, authorised devices access organisational systems. This maps to MDM and GPO controls for device compliance enforcement. Akku’s mapping shows GPO Manager addresses PR.AA.S15 across multiple guideline references, and Mobile Device Manager addresses it across 21 total guideline mappings, the highest single-module count in the entire SEBI mapping.
PR.AA.S16 and PR.AA.S17 cover external user and customer access controls, including authentication requirements for non-employee users accessing organisational systems or customer-facing platforms.
How Akku addresses it
Akku’s unified cloud identity store provides the centralised identity management infrastructure that PR.AA.S1 requires. Every user has a unique identity in the Akku directory. SSO with a centralised IdP consolidates authentication across applications, eliminating the fragmented credential landscape that PR.AA.S1 is designed to prevent.
RBAC and ABAC enforce least privilege at the access layer. The IGA SoD rules engine enforces segregation of duties, detecting conflicting role combinations and triggering remediation. Contextual access controls apply IP, device, time-of-day, and geo-location restrictions, satisfying PR.AA.S4’s risk-based access control requirement.
Adaptive MFA evaluates risk signals at each authentication event and escalates the challenge proportionately. This is the authentication model PR.AA.S7 requires. For privileged infrastructure access, MFA is enforced at the IAM layer through PAM before any session proxy connection opens.
Privileged Access Requirements Under PR.AA.S10 to S12
PR.AA.S10 through S12 address privileged access management specifically. These guidelines require that privileged accounts be separately managed, that privileged sessions be monitored and logged, and that privileged access be granted on a just-in-time basis where possible.
What the framework requires
PR.AA.S10 requires that privileged accounts be separately identified, managed, and monitored. Privileged users must not use privileged credentials for routine, non-administrative tasks.
PR.AA.S11 requires that privileged access be granted based on formal approval, with access scope defined and time-limited where possible. Standing privilege with no defined scope or time limit is inconsistent with this requirement.
PR.AA.S12 requires that all privileged sessions be logged with sufficient detail to reconstruct the actions taken. Authentication records alone do not satisfy this requirement.
GV.RM.S1 and GV.RM.S2 require that risk management controls include governance of high-privilege access as a specific risk category.
How Akku addresses it
AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, injected at the protocol layer by AkkuReka, and permanently revoked on session close. No privileged user holds standing credentials to target systems. This directly satisfies PR.AA.S11’s time-limited, scope-defined access requirement.
The session approval workflow produces the formal authorisation record PR.AA.S11 requires. Every privileged session request includes target system, requested access level, duration, and justification. Approval decisions are logged with approver identity and timestamp.
SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka. SSH sessions produce full screen recordings and complete keystroke logs. Database sessions produce full screen recordings and structured SQL query capture. This is the session-level evidence that PR.AA.S12 requires and that authentication logs cannot provide.
Real-time session monitoring allows administrators to view all active privileged sessions and terminate any session instantly. Session termination is recorded in the audit log with actor, timestamp, and reason. Akku’s SEBI mapping shows Privileged Access Manager addresses PR.AA.S11, PR.AA.S10 to S12 guidelines, and GV.RM.S1 to S2 references across 12 total guideline mappings.
Audit Log and Monitoring Requirements Under DE.CM and GV.OC
The Detect function’s continuous monitoring requirements and the Govern function’s on-demand log access requirements are where many SEBI-regulated entities have significant compliance gaps. The requirements go beyond storing logs to requiring structured, searchable, exportable audit trails accessible to SEBI on demand.
What the framework requires
GV.OC.S2(G2) requires that logs, user details, and application data be accessible to SEBI on demand. This is not a notification requirement. It is an on-demand data access obligation. The infrastructure must be capable of producing structured log exports at any time, covering any requested period.
GV.OC.S2(G3) requires that privileged user responsibilities be formally defined and that audit records reflect the scope of each privileged user’s authorised activities.
DE.CM.S1 through S3 require continuous monitoring of system components, including authentication events, access patterns, and privileged activity. Monitoring must be capable of detecting anomalies and generating alerts.
PR.AA.S8 requires that all authentication events be logged with actor identity, timestamp, source, and outcome. PR.AA.S12 requires that privileged session activity be logged at the command and query level.
RS.AN.S1 through S5 require that incident response activities be supported by structured log evidence enabling rapid scoping and attribution of security incidents.
How Akku addresses it
Akku’s audit log architecture is append-only and tamper-evident. Every authentication event, access event, privileged session lifecycle event, administrative action, and policy change produces a structured log record. Logs are exportable in JSON and CSV format and accessible via API for programmatic integration with SIEM and log aggregation platforms.
The GV.OC.S2(G3) on-demand access requirement is satisfied through Akku’s exportable audit trail infrastructure. Log exports can be produced for any time period, filtered by user, system, event type, or outcome, and submitted to SEBI in structured format.
SMARTAudit Trails provide the session-level logging that DE.CM and PR.AA.S12 require for privileged access. Every privileged command and database query is captured, indexed, and searchable. This is the evidence layer that supports the incident response scoping requirements in RS.AN.
Akku’s identity and access security monitoring layer captures authentication anomalies including MFA failure spikes, logins from new geographic locations, access outside defined time windows, and behavioural deviations. Risk and audit dashboards surface these patterns for investigation. Akku’s SEBI mapping shows the Audit Logs module addresses 20 guideline references, the second highest after Mobile Device Manager’s 21.
Dormant Account and Lifecycle Management Requirements
SEBI CSCRF contains specific requirements for dormant account management and user lifecycle controls that are frequently underimplemented at regulated entities. Dormant accounts with active credentials represent a persistent access risk that several PR.AA guidelines specifically address.
What the framework requires
PR.AA.S1(G1g) and PR.AA.S1(G1h) require that user accounts inactive beyond a defined threshold be automatically disabled. Manual processes for dormant account identification and disabling are insufficient at the scale most regulated entities operate.
PR.AA.S6(G2) requires that credentials associated with dormant or terminated accounts be revoked or invalidated. An account that is disabled at the application layer but retains valid credentials in a connected system is not fully deprovisioned.
GV.SC.S4 requires that third-party and supply chain access be governed through the same lifecycle controls as internal users, including time-bound access and prompt revocation on engagement end.
PR.DS.S6(G3) requires that data access entitlements be reviewed when users change roles or functions, not only at termination.
How Akku addresses it
Automated User Lifecycle Management covers the full joiner-mover-leaver workflow with automated dormant account detection. Accounts inactive beyond a configured threshold are automatically flagged and disabled. The detection run and disabling action produce a timestamped audit record of the dormant account management process.
The IGA orphan account management capability detects accounts without a linked, active identity across all connected applications, including accounts created during migrations, temporary access grants, and incomplete deprovisioning from prior role changes. These are surfaced for resolution through deletion or reassignment.
SCIM-based automated provisioning ensures that deprovisioning actions in Akku propagate to connected applications. Access revoked in the IAM layer is removed from downstream systems without manual intervention. Connector health monitoring detects silent sync failures before they result in access gaps.
Access review and re-certification campaigns address PR.DS.S6(G3)’s role-change access review requirement. When a user changes roles, a targeted recertification of their existing entitlements can be triggered, ensuring that access accumulated in the previous role is reviewed and revoked where no longer appropriate. Akku’s SEBI mapping shows User Lifecycle Manager addresses seven guideline references across PR.AA.S1, GV.SC.S4, and PR.DS.S6.
How IAM Addresses SEBI CSCRF’s Technical Obligations
Akku’s SEBI CSCRF compliance mapping covers 88 unique compliance items from the 232 Part II guidelines, with 145 total clause mappings across 12 platform modules. This is the highest compliance coverage number across all frameworks in Akku’s mapping documentation, reflecting the CSCRF’s detailed and technically specific requirements in the areas that IAM directly addresses.
The module coverage breakdown reflects the framework’s emphasis on endpoint governance and audit trail depth. Mobile Device Manager carries 21 guideline mappings, the highest single-module count, reflecting SEBI CSCRF’s detailed device and endpoint security requirements across PR.AA.S15, PR.AA.S16 to S17, and PR.DS.S1 to S3. GPO Manager carries 17 mappings across device access, data protection, and network controls. Audit Logs carries 20 mappings covering GV.OC, PR.AA.S8, PR.AA.S12, DE.CM, RS.AN, and EV.ST sub-categories.
An important scoping note: the 88 compliance items Akku covers represent the IAM and endpoint security addressable layer of SEBI CSCRF. The remaining guidelines cover network security, vulnerability management, business continuity, incident management, and governance requirements that are outside the scope of IAM platforms. Full CSCRF compliance requires these technical controls combined with the operational and governance measures the framework’s remaining requirements specify.
Questions SEBI-Regulated Entities Ask About IAM Technical Controls Under CSCRF
Which SEBI-regulated entities are subject to CSCRF and what determines their tier?
SEBI CSCRF applies to all SEBI-regulated entities including stock brokers, depository participants, asset management companies, portfolio managers, investment advisers, registrars and transfer agents, and market infrastructure institutions. Entity tier is determined by factors including trading volume, assets under management, number of clients, and systemic importance. Market Infrastructure Institutions face the highest tier requirements. Qualified REs face enhanced requirements above the baseline. Mid-size and Small REs face baseline requirements. Entities should assess their tier classification carefully as it determines which guideline levels within each sub-category apply.
What does SEBI CSCRF PR.AA.S7 require for authentication, and how does adaptive MFA satisfy it?
PR.AA.S7 requires that authentication controls be commensurate with the sensitivity of the resource being accessed. This proportionality requirement means that high-sensitivity systems require stronger authentication than low-sensitivity ones, and that the authentication model must be capable of adjusting based on risk context. Adaptive MFA satisfies this by evaluating risk signals at each authentication event including device posture, location, IP reputation, and behavioural baseline, and escalating the challenge for high-sensitivity access or anomalous contexts. Static MFA applied uniformly does not satisfy the proportionality requirement.
What does GV.OC.S2(G3) require for on-demand log access, and what does this mean technically?
GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. Technically, this means the audit infrastructure must be capable of producing structured log exports covering any requested time period, filtered by user, system, or event type, in a format SEBI can examine. This requires an append-only, tamper-evident audit log with structured export capability, not a collection of application-specific logs that require manual compilation. The integrity of the log must also be demonstrable, meaning records cannot have been modified after the fact.
How does SEBI CSCRF address dormant account management, and what does automated disabling require technically?
PR.AA.S1(G1g) and G1h require that accounts inactive beyond a defined threshold be automatically disabled. Technically, this requires an identity governance platform that monitors last-activity timestamps across connected applications, compares them against a configured inactivity threshold, and triggers automatic account disabling without manual intervention. The disabling action must produce a timestamped audit record. Manual dormant account reviews conducted periodically do not satisfy the automation requirement at the scale most SEBI-regulated entities operate.
What is the difference between PR.AA.S11 and PR.AA.S12, and why do both require separate technical controls?
PR.AA.S11 covers the authorisation and governance of privileged access: how access is requested, approved, scoped, and time-limited. PR.AA.S12 covers the logging of privileged session activity: what the privileged user did once access was granted. Both are required but they address different layers. PR.AA.S11 is satisfied by a structured session request and approval workflow with per-session ephemeral credentials and JIT access. PR.AA.S12 is satisfied by protocol-level session recording through SMARTAudit Trails capturing keystrokes and SQL queries. Satisfying one does not satisfy the other.
Can a single IAM deployment address both SEBI CSCRF and ISO 27001 requirements simultaneously?
Yes. The overlapping technical controls are substantial. SEBI CSCRF PR.AA.S7 and ISO 27001 A.8.5 both require secure, proportionate authentication. SEBI CSCRF PR.AA.S12 and ISO 27001 A.8.15 both require user activity logging beyond authentication records. SEBI CSCRF PR.AA.S11 and ISO 27001 A.8.2 both require least-privilege, time-bound privileged access. A single IAM deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.
