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 departed users’ accounts be removed promptly. These are the access hygiene requirements within the broader PR.AA identity management sub-category, and they are consistently among the findings in SEBI CSCRF examinations at capital markets entities.
Dormant accounts accumulate for predictable reasons. Employees leave without a formal IT deprovisioning trigger. Contractors’ engagements end with access removal overlooked in the offboarding process. Accounts created for specific projects persist after the projects conclude. Service accounts outlive the services they were created for. Each of these creates an account that exists without an active, legitimate owner, holds valid credentials, and represents an attack surface that grows invisibly over time.
The access hygiene framing in SEBI CSCRF is deliberate. Access hygiene is not a one-time cleanup exercise. It is a continuous operational discipline: accounts are monitored for inactivity, disabled when they cross the threshold, removed when the owner relationship is confirmed gone, and reviewed periodically to prevent silent accumulation. The automatic requirement in PR.AA.S1(G1g) means this discipline must be technically enforced, not manually managed through periodic reviews.
This blog covers what PR.AA.S1(G1g) and G1h specifically require, how dormant accounts accumulate and why manual controls fail to address them reliably, and how automated dormant account management satisfies the SEBI CSCRF access hygiene standard.
PR.AA.S1 covers identity management and user registration requirements under SEBI CSCRF. G1g and G1h are the specific guidelines addressing account lifecycle at the inactive and departed user layer.
G1g requires that user accounts inactive beyond a defined threshold be automatically disabled. The automatic requirement is not satisfied by a process where a system produces a report of inactive accounts that an administrator then reviews and manually disables. The disabling must occur through an automated technical control triggered by the inactivity threshold being crossed.
The inactivity threshold must be defined and configured in the identity management platform. The platform must monitor last authentication timestamps for all user accounts continuously and trigger the disabling action when the threshold is crossed without requiring administrator initiation.
The disabling event must generate a timestamped audit record. For SEBI examination purposes, the audit record demonstrates that the automated control operated, that the threshold was crossed, and that disabling occurred at the appropriate time.
G1h requires that accounts belonging to users who have left the organisation be removed promptly. Promptly implies a short timeframe: SEBI examination practice treats same-day or next-day removal as compliant for employment terminations. Accounts that persist for days or weeks after departure are findings.
Prompt removal requires an automated deprovisioning workflow triggered by the HR system event recording the departure. Manual deprovisioning that depends on an IT ticket being raised after the HR event creates a gap between the departure event and the access removal. For high-risk environments such as capital markets entities, this gap represents meaningful exposure.
Removal under G1h differs from disabling under G1g. G1g disabling is a reversible action taken when an account crosses an inactivity threshold, pending investigation of whether the account should be retained or removed. G1h removal is a definitive action taken when the user’s departure is confirmed, removing the account entirely from the access infrastructure.
Understanding how dormant accounts accumulate is necessary for designing controls that prevent accumulation rather than periodically cleaning it up.
The most common source of dormant accounts is incomplete offboarding. When an employee leaves, the HR system records the departure and initiates the payroll and benefits offboarding. IT offboarding, which should include access revocation across all connected systems, may not be triggered automatically from the HR event. If IT offboarding requires a separate ticket or notification from the line manager, and that notification is delayed or overlooked, the employee’s accounts persist.
At scale, the gap between HR departure records and IT access revocation produces a consistent backlog of accounts belonging to departed employees. Monthly or quarterly access reviews surface these gaps retrospectively. G1h’s prompt removal requirement means they must be addressed at the time of departure.
Contractor access is particularly prone to dormant account accumulation because contractor departures are less formally managed than permanent employee departures. When a contractor’s statement of work ends, the contractor stops attending but the IT offboarding trigger may not exist. Without a formal engagement end trigger in the identity management platform, the contractor’s accounts persist indefinitely.
Service provider and vendor accounts created for specific integrations or support access face the same issue. The initial access provisioning may follow a formal process, but the deprovisioning trigger when the relationship ends is often absent.
Access granted for specific projects, system migrations, or temporary cross-functional assignments may not have defined expiry dates. When the project concludes, the temporary access persists because there is no technical expiry mechanism and no deprovisioning trigger in the lifecycle management workflow.
Service accounts created for application integrations, automated processes, and system-to-system communications accumulate over time as applications are upgraded or replaced. The old service account may remain active after the integration is replaced with a newer version, holding credentials and potentially access to systems it no longer needs to reach.
G1g’s automatic requirement is specific. A quarterly dormant account review that identifies inactive accounts and queues them for administrator action is not an automated control. It is a manual process with automated discovery. The distinction matters for two reasons.
A quarterly review has a three-month gap during which dormant accounts accumulate unchecked. An account that crosses the inactivity threshold in the first week of the quarter remains active for up to three months before the next review catches it. During this window, the dormant account represents an unmonitored attack surface.
Automated threshold enforcement closes this gap. When the threshold is crossed, the account is disabled immediately. The gap is reduced to the monitoring check interval, typically hours, not the review cycle interval of months.
A capital markets entity with thousands of users across dozens of connected applications cannot reliably manage dormant account identification and disabling through manual review processes. Manual processes produce inconsistent results at scale: some accounts are caught promptly, others persist through multiple review cycles due to oversight or competing workload priorities.
Automated threshold enforcement applies consistently to every account. No account is overlooked because an administrator had higher-priority work during the review cycle.
Akku’s User Lifecycle Manager implements G1g and G1h requirements through continuous activity monitoring and threshold-based automated enforcement.
The centralised authentication event log captures every authentication event across all connected applications. The User Lifecycle Manager monitors the last authentication timestamp for every user identity in the Akku directory against a configured inactivity threshold.
For accounts that authenticate through Akku’s centralised SSO, activity monitoring is comprehensive. For legacy applications that do not route authentication through Akku, activity monitoring covers the centralised layer but not direct application authentication. Full G1g coverage requires all applications to authenticate through the centralised IdP so that inactivity can be detected comprehensively.
Inactivity thresholds are configurable per organisational unit or user group. A 90-day threshold for standard employee accounts and a 30-day threshold for privileged accounts are common configurations at capital markets entities. Service accounts can be given separate threshold policies that account for their legitimate inactivity patterns.
The threshold must be defined in the IT security policy and technically configured to match. An auditor examining G1g compliance will verify both the policy definition and the platform configuration.
When an account crosses the threshold, the User Lifecycle Manager automatically disables the account in the Akku directory and triggers deprovisioning notifications to connected applications via SCIM. The disabling event generates a timestamped audit record capturing account identity, triggering threshold, last activity timestamp, and disabling timestamp.
This audit record is the G1g compliance evidence. It demonstrates that the automated control operated, that the threshold was applied at the correct time, and that the disabling action was executed without administrator initiation.
G1h’s prompt removal requirement is addressed through Akku’s automated deprovisioning workflow. When an employee departure is recorded in the HR system, the event triggers Akku’s deprovisioning workflow through SCIM or API integration. Deprovisioning across all connected applications is initiated simultaneously, with SCIM sync confirmation records generated for each application.
The deprovisioning audit trail covering every system from which access was removed, with timestamps and sync confirmations, is the G1h compliance evidence. The trigger timestamp from the HR system event and the deprovisioning completion timestamps together demonstrate that removal was prompt.
Automated G1g and G1h controls prevent new dormant accounts from accumulating going forward. They do not address dormant accounts that existed before the controls were implemented. Orphan account detection addresses the historical backlog.
Akku’s IGA orphan account management scans all connected applications for accounts that exist without a linked, active identity in the Akku directory. Accounts belonging to departed employees who were not deprovisioned completely, contractor accounts persisting after engagement end, and project access accounts with no current owner are identified in the scan.
Each identified orphan is surfaced for resolution through deletion or reassignment. The detection run and resolution record demonstrate proactive access hygiene beyond the threshold-based controls that G1g and G1h require. SEBI examiners looking for evidence of access hygiene discipline will find both the automated threshold controls and the orphan detection records as complementary evidence of a complete programme.
Does your identity management platform automatically disable accounts when they cross a configured inactivity threshold without requiring administrator initiation, or does dormant account management rely on periodic reports and manual review?
For accounts disabled through the automated dormant account control in the last 12 months, is there a timestamped audit record for each disabling event showing the account identity, threshold crossed, and disabling timestamp?
When an employee departure is recorded in the HR system, does access revocation across all connected applications complete within the same business day through an automated workflow, or does it require a separate IT ticket or manual trigger?
Has your organisation run an orphan account detection scan in the last 90 days to identify accounts across connected applications that exist without a linked, active identity, and is there a resolution record for every orphan identified?
Does your inactivity monitoring cover all systems that user accounts can authenticate to, or only systems that route through the centralised identity layer, leaving direct application authentication outside the monitoring scope?
See how Akku’s User Lifecycle Manager addresses SEBI CSCRF dormant account requirements through automated threshold enforcement, departure-triggered deprovisioning, and orphan account detection.
Book a conversation with the Akku team to assess your current dormant account controls against SEBI CSCRF PR.AA.S1 access hygiene requirements.
What inactivity threshold should capital markets entities configure for G1g compliance?
SEBI CSCRF does not specify a precise inactivity threshold in G1g. Industry practice at capital markets entities typically applies 90 days for standard employee accounts and 30 days for privileged accounts with access to critical trading or settlement systems. The threshold must be defined in the IT security policy and technically configured in the identity management platform. Shorter thresholds for higher-risk accounts reflect the access hygiene principle: accounts with greater access privilege represent greater dormant risk and warrant earlier disabling. SEBI examiners will assess whether the configured threshold is proportionate to the risk profile of the user population it covers.
Does G1g apply to service accounts as well as human user accounts?
Yes. G1g applies to all user accounts including service accounts. Service accounts present a configuration challenge because they may have legitimate periods of inactivity. A batch processing service account that runs monthly will appear inactive for 29 of every 30 days. Applying a standard 90-day threshold to this account would disable it before its next scheduled run. The solution is separate inactivity threshold policies for service accounts, configured based on the known activity schedule of each service account category. Service accounts with no documented activity schedule should be treated as candidates for removal through orphan account management rather than threshold-based disabling.
What is the difference between account disabling under G1g and account removal under G1h?
Account disabling under G1g is triggered by inactivity threshold crossing. It is a reversible action that prevents authentication while preserving the account record and its audit history pending investigation. The account may belong to an employee on extended leave, in which case it can be re-enabled with manager approval when they return. Account removal under G1h is triggered by confirmed departure. It is a definitive action that removes the account from the access infrastructure following the departure event. The distinction matters because G1g disabling may require a reinstatement process for legitimate returns, while G1h removal does not.
How should capital markets entities handle accounts belonging to employees on extended leave under G1g?
Employees on extended leave, such as maternity or paternity leave, long-term medical leave, or sabbatical, may cross the inactivity threshold without representing a dormant account risk in the traditional sense. The recommended approach is to configure a separate inactivity policy for accounts in defined leave status, with either a longer threshold or a hold that prevents automatic disabling during the leave period. The leave status must be sourced from an authoritative HR system and applied to the account when leave begins. When leave ends, the standard threshold applies from the return date. Accounts on leave hold should still be reviewed periodically as part of the broader access governance programme.
Can the same automated dormant account management capability satisfy both SEBI CSCRF G1g and IRDAI Item 10 simultaneously?
Yes. SEBI CSCRF PR.AA.S1(G1g) and IRDAI ICS Item 10 both require automatic disabling of accounts inactive beyond a defined threshold. The same automated dormant account management capability in Akku’s User Lifecycle Manager satisfies both requirements from the same technical control. The threshold configuration, activity monitoring, automatic disabling, SCIM-based downstream notification, and audit record generation are identical for both frameworks. The compliance mapping references differ, but the technical control and the evidence it produces are the same. Organisations subject to both SEBI CSCRF and IRDAI ICS benefit from this overlap: one control deployment, one evidence trail, two framework requirements satisfied.
What does SEBI expect to see during an examination of dormant account controls specifically?
SEBI examiners reviewing dormant account controls under PR.AA.S1 typically request evidence of the automated disabling mechanism configuration showing the threshold is technically enforced. They request a sample of disabling events from the audit log showing timestamped records generated automatically when thresholds were crossed during the examination period. They verify that the disabling events were generated by the automated control, not by manual administrator action following a report. They also examine whether disabled accounts had their access to connected applications revoked, requiring SCIM deprovisioning confirmation records alongside the identity platform disabling records. Finally, they may request an orphan account scan result showing the current state of accounts across connected applications.
Introduction IRDAI ICS Annexure III Item 10 requires that user accounts inactive beyond a defined…
Introduction ISO 27001:2022 Annex A.5.18 requires that access rights be reviewed at regular intervals and…
Introduction SOC 2 Trust Services Criteria CC5.1 requires that the entity selects and develops control…
Introduction SEBI CSCRF applies to all regulated entities but differentiates requirements by entity tier. Market…
Introduction ISO 27001:2022 Annex A.8.2 requires that the allocation and use of privileged access rights…
Introduction ISO 27001:2022 introduced A.8.16 as a new control with no direct equivalent in the…