SEBI CSCRF’s Protect function contains the Access Authentication sub-category PR.AA, which runs from PR.AA.S1 through PR.AA.S17 and represents the most detailed set of identity and access management requirements in any Indian regulatory framework. The Detect function’s continuous monitoring sub-category DE.CM adds a layer of anomaly detection and real-time visibility requirements that most capital markets entities are not currently meeting at the depth the framework requires.
Together, PR.AA and DE.CM define what SEBI expects from a capital markets entity’s identity stack. PR.AA covers how identities are managed, how access is provisioned, how credentials are controlled, how authentication is enforced, and how privileged access is governed. DE.CM covers how authentication events and access patterns are monitored continuously, and how anomalies are detected and acted upon.
Most SEBI-regulated entities have implemented some subset of these controls. SSO is deployed for application access. MFA is enforced at the application login layer. Some form of access review is conducted periodically. What the framework requires goes further: proportionate, risk-based authentication for every access scenario, privileged access governance with session-level recording, continuous monitoring with anomaly detection, and on-demand log access for SEBI examination.
This blog covers what PR.AA and DE.CM specifically require at the technical implementation level, with direct references to guideline codes from the SEBI CSCRF Part II and Akku’s SEBI compliance mapping documentation, which covers 88 unique compliance items with 145 total clause mappings.
PR.AA.S1 through PR.AA.S6 cover the foundational identity management layer: unique identification, centralised identity management, credential governance, and access provisioning based on least privilege.
PR.AA.S1 requires that all users, whether employees, contractors, or third parties, be uniquely identified. Shared accounts and generic credentials are inconsistent with this requirement. Each identity must be individually accountable. PR.AA.S1 guideline references G1e, G1g, G1h, and G2 in Akku’s SEBI mapping cover user registration, lifecycle management, and dormant account controls under this sub-section.
PR.AA.S6 requires strong credential management covering password policies, credential storage security, and the full credential lifecycle. Password complexity, length, expiry, and history requirements must be technically enforced. Credentials must be stored in an encrypted vault with access controls preventing direct human access to raw credential data. Akku’s SEBI mapping shows Password Manager addresses PR.AA.S6 across eight guideline references including G1, G1f, G3, G3b, G4h.
PR.AA.S3 and PR.AA.S5 require that access be provisioned based on formally defined roles, with least privilege enforced throughout the access lifecycle. Access beyond role defaults requires documented justification and approval. Identity and Access Governance addresses PR.AA.S3 and PR.AA.S5 across 12 total guideline mappings covering role governance, access certification, and SoD enforcement.
PR.AA.S4 requires that access controls be applied based on risk, with more sensitive resources receiving stricter access controls. This is not a uniform access control requirement. It is a risk-stratified model where the access control applied to a trading system is more restrictive than the one applied to an internal wiki. Access Manager addresses PR.AA.S4 across 13 guideline mappings, the highest single-module count after GPO Manager and Audit Logs in the SEBI mapping.
Akku’s unified cloud identity store provides the centralised identity management infrastructure PR.AA.S1 requires. Every user has a unique identity in the Akku directory. The User Lifecycle Manager automates the joiner-mover-leaver workflow, ensuring identities are created, updated, and removed through structured processes with full audit trails. Akku’s SEBI mapping shows User Lifecycle Manager addresses PR.AA.S1 guideline references G1g and G1h, GV.SC.S4, and PR.DS.S6(G3) across seven total mappings.
RBAC and ABAC enforce least privilege at the access layer. Role definitions determine application and resource access. Attribute-based controls refine this by factoring in department, location, employment type, and device compliance status. The IGA SoD rules engine defines conflicting role combinations, detects violations continuously, and triggers automated remediation.
Password Manager addresses PR.AA.S6’s credential governance requirements. Password policies enforce complexity, length, expiry, history, and lockout rules at the organisation, group, or role level. AkkuVault stores credentials encrypted with AES-256-GCM. Vault contents are accessible only via the AkkuArka API, with no direct human access to raw credential data.
PR.AA.S7 through PR.AA.S9 cover authentication controls, MFA enforcement, and the proportionality requirement that distinguishes SEBI CSCRF’s authentication model from a simple MFA deployment.
PR.AA.S7 requires that authentication controls be commensurate with the sensitivity of the resource being accessed. A trading system, a core settlement platform, and a network management interface require stronger authentication than an internal documentation system. The proportionality requirement means that authentication strength must scale with resource sensitivity, not be applied uniformly.
PR.AA.S9 requires that MFA be enforced for access to sensitive and critical systems. For capital markets entities, this includes trading platforms, clearing systems, client data repositories, and network infrastructure management interfaces. The scope extends beyond application-layer authentication to infrastructure-level access.
PR.AA.S10 through PR.AA.S12 cover privileged access specifically, which is addressed in the next section.
Guideline references G1i and G1j under PR.AA.S1 to S9 cover authentication logging requirements, specifying that every authentication event must be logged with sufficient detail for audit and investigation purposes. Akku’s SEBI mapping shows Adaptive MFA addresses PR.AA.S7 and 10 additional guideline references across the PR.AA sub-category.
Akku’s Adaptive MFA evaluates device posture, geographic location, IP reputation, time of day, and behavioural baseline at each authentication event. The challenge escalates when risk signals indicate elevated risk. This is the proportionate, risk-based authentication model PR.AA.S7 requires. A static second factor applied uniformly to all sessions does not satisfy the proportionality requirement.
For infrastructure-level access, Akku extends MFA enforcement to privileged sessions through PAM. A privileged user must authenticate to Akku IAM with MFA before AkkuReka opens a session to the target system. This covers SSH servers, RDP hosts, MySQL and PostgreSQL databases, Kubernetes clusters, and web applications at the infrastructure layer.
Every authentication event produces a structured log record containing actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome. This event stream is the continuous authentication evidence that PR.AA.S8’s logging requirement and DE.CM’s monitoring requirement draw on.
PR.AA.S10 through PR.AA.S12 define SEBI CSCRF’s privileged access management standard. These guidelines go beyond credential storage to require session-level governance, formal approval workflows, and activity-level logging.
PR.AA.S10 requires that privileged accounts be separately identified and managed. Privileged users must not use privileged credentials for routine non-administrative tasks. Each privileged account must be individually accountable, with no shared administrative credentials.
PR.AA.S11 requires that privileged access be granted based on formal approval, with access scope defined and time-limited where possible. GV.RM.S1(G1c) reinforces this by requiring that high-privilege access be treated as a specific risk category within the entity’s risk management framework.
PR.AA.S12 requires that all privileged session activity be logged with sufficient detail to reconstruct the actions taken. Authentication records alone do not satisfy this requirement. The log must capture what the privileged user did, not only that they connected. Akku’s SEBI mapping shows Privileged Access Manager addresses PR.AA.S11, guidelines G2a, G2b, G2c under PR.AA.S10 to S12, PR.AA.S15(G4c), PR.DS.S4(G2), PR.MA.S2(G3), and GV.RM.S1 to S2(G1c) across 12 total guideline mappings.
AkkuArka generates per-session ephemeral credentials for every privileged session. No privileged user holds standing credentials to target systems. Each session uses a unique credential generated at approval and permanently revoked on session close. This directly satisfies PR.AA.S10’s individual accountability requirement and PR.AA.S11’s time-limited access requirement.
The session approval workflow produces the formal authorisation record PR.AA.S11 requires. Every privileged session request captures target system, access level, duration, and justification. Approval decisions are logged with approver identity and timestamp. No session opens without approval when the workflow is enabled.
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. RDP sessions produce full screen video recordings. This is the activity-level logging 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. Termination is recorded in the audit log with actor, timestamp, and reason.
DE.CM, the continuous monitoring sub-category of the Detect function, adds a proactive detection layer on top of the logging requirements in PR.AA. The distinction between logging and monitoring is central to what DE.CM requires: logs record what happened, monitoring detects anomalies as they occur or shortly after.
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 indicative of malicious activity, unauthorised access, or policy violations.
DE.CM requires that monitoring be automated and continuous, not periodic. A weekly review of authentication logs does not satisfy continuous monitoring. The monitoring infrastructure must evaluate events against baselines and generate alerts without waiting for manual review cycles.
RS.AN.S1 through S5 in the Respond function require that incident response activities be supported by structured log evidence enabling rapid scoping and attribution. This reinforces the quality and completeness requirements for the underlying log infrastructure that DE.CM monitors.
Akku’s SEBI mapping shows Audit Logs addresses DE.CM.S1 to S3(G1) alongside RS.AN.S1 to S3(G1 to G4), RS.AN.S4 to S5(G1 to G5), EV.ST.S1 to S3(G5 to G6), and EV.ST.S1 to S3(G7 to G8) across 20 total guideline mappings, the second highest single-module count in the SEBI mapping after Mobile Device Manager.
Akku’s Adaptive MFA provides anomaly detection at the authentication layer. AI-powered analysis evaluates each authentication event against the user’s behavioural baseline. Deviations in location, device, time-of-day, or access pattern trigger step-up authentication challenges and generate security events for administrator review.
Risk and audit dashboards surface MFA failure spikes, geographic anomalies, access outside defined time windows, and behavioural deviations as actionable alerts. These are the real-time signals that DE.CM requires to be detected automatically, not discovered through periodic log review.
For privileged access, real-time session monitoring through AkkuReka provides the continuous visibility DE.CM requires at the infrastructure layer. Administrators view active sessions and can act on anomalous behaviour immediately rather than retrospectively.
The append-only, tamper-evident audit log architecture ensures that the event records DE.CM monitors cannot be modified after the fact. Logs are exportable in JSON and CSV format and accessible via API for integration with SIEM and log aggregation platforms, supporting the RS.AN incident response evidence requirements.
GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. This is a structural requirement about log architecture, not a notification obligation. The infrastructure must be capable of producing structured exports at any time covering any requested period.
On-demand log access requires a centralised, queryable log infrastructure with structured export capability. Logs distributed across individual application log files that require manual compilation before export do not satisfy the on-demand requirement. The export must be producible in structured format, such as JSON or CSV, within a timeframe consistent with a regulatory request.
The integrity of the exported logs must be demonstrable. An append-only architecture that prevents post-hoc modification is what makes the integrity claim credible. A log that can be edited before export cannot satisfy a regulatory examination where the accuracy of the records is under scrutiny.
Akku’s centralised audit log provides a single queryable source for all authentication events, access events, privileged session records, administrative actions, and policy changes. Exports can be produced for any time period, filtered by user, system, event type, or outcome, in JSON or CSV format. API access enables programmatic integration with SIEM, SOAR, and log aggregation platforms.
The append-only architecture ensures that records cannot be modified after the fact. GV.OC.S2(G2) and GV.OC.S2(G3) are addressed by Audit Logs alongside Cloud Directory in Akku’s SEBI mapping.
For any 30-day window SEBI requests, can you produce a structured export of all authentication events, privileged session records, and access change events across your environment without manual log compilation?
Does your MFA deployment apply proportionately stronger authentication to your trading systems and settlement platforms than to lower-sensitivity internal applications, or is MFA applied uniformly regardless of resource sensitivity?
When a privileged user accesses a trading platform database or network management interface, is there a session recording capturing every query executed and every command run, not only an authentication log confirming the session occurred?
Are dormant accounts automatically disabled after a defined inactivity threshold, with a timestamped audit record of each disabling action, or does dormant account management rely on periodic manual review?
Does your monitoring infrastructure detect MFA failure spikes and geographic authentication anomalies in real time and generate alerts for administrator review, or are these patterns discovered during periodic log review?
What does PR.AA.S7’s proportionality requirement mean in practice for a capital markets entity?
PR.AA.S7 requires that authentication controls be commensurate with the sensitivity of the resource. For a capital markets entity, this means that trading platforms, clearing systems, and client data repositories require stronger authentication than internal administrative tools. In practice, this is implemented through Adaptive MFA that evaluates risk signals at each authentication event and escalates the challenge for higher-sensitivity access scenarios. A static second factor applied uniformly to all sessions, regardless of what is being accessed, does not satisfy the proportionality requirement.
What is the difference between PR.AA.S11 and PR.AA.S12, and why do both require separate controls?
PR.AA.S11 covers the authorisation and governance of privileged access: how sessions are requested, approved, scoped, and time-limited. PR.AA.S12 covers the logging of what happened during privileged sessions: commands executed, queries run, actions taken. PR.AA.S11 is satisfied by a structured session approval workflow with per-session ephemeral credentials and JIT access. PR.AA.S12 is satisfied by protocol-level session recording through SMARTAudit Trails. Satisfying one does not satisfy the other.
What does DE.CM require for continuous monitoring, and how is this different from periodic log review?
DE.CM requires continuous monitoring of system components including authentication events, access patterns, and privileged activity, with automated detection of anomalies. Periodic log review involves examining accumulated logs on a defined schedule, typically daily or weekly. Continuous monitoring evaluates events against baselines as they occur and generates alerts without waiting for a review cycle. The distinction matters because a credential stuffing attack that completes within hours leaves the detection window before a daily log review occurs. Continuous monitoring with real-time alerting is the control DE.CM requires.
What does GV.OC.S2(G3) require for on-demand log access, and what does this mean for log architecture?
GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. Architecturally, this requires a centralised, queryable log infrastructure capable of producing structured exports for any requested time period without manual compilation. Logs distributed across individual application systems that require aggregation before they can be exported do not satisfy the on-demand requirement. The export must be producible in structured format within a timeframe consistent with a regulatory request, and the integrity of the records must be demonstrable through an append-only architecture.
How does the SoD rules engine address PR.AA.S3’s access control requirements for capital markets entities?
PR.AA.S3 requires that access be provisioned based on formally defined roles with least privilege enforced. For capital markets entities, SoD requirements are particularly stringent because conflicts of interest between front-office trading, back-office settlement, and compliance functions create direct regulatory risk. The SoD rules engine defines conflicting role combinations specific to the entity’s operational structure, detects violations continuously across connected applications, and triggers automated remediation workflows. This technical enforcement is what distinguishes a compliant SoD posture from a policy document stating that SoD is required.
Can a single IAM deployment address both SEBI CSCRF and RBI requirements for entities regulated by both?
Yes. The overlapping technical controls are substantial. SEBI CSCRF PR.AA.S7 and RBI Clause 19(c) both require proportionate, risk-based MFA for privileged access. SEBI CSCRF PR.AA.S12 and RBI Clause 15 both require session-level activity logging for privileged users. SEBI CSCRF GV.OC.S2(G3) and RBI Clause 15 both require on-demand log access with demonstrable integrity. A single Akku deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.
Introduction RBI 2023 Master Direction Clause 19 is the most technically detailed access control provision in the framework. It establishes…
Introduction DPDPA Clause 6 sets specific conditions for consent as a lawful basis for processing personal data. Consent must be…
Introduction Most IT teams at regulated organisations experience compliance audits as events. A notice arrives. A scramble begins. Access records…
Introduction IRDAI ICS Annexure III Item 14 requires that all access to organisational systems be authenticated through a centralised authentication…
Indian companies with EU customers, EU operations, or EU-based employees are subject to the General Data Protection Regulation regardless of…
SOC 2 Type II has become a commercial prerequisite for Indian ITeS and BPO companies serving enterprise clients in North…