Sectona at Infosecurity Europe 2025 | June 3–5 | ExCeL London
Stop by our booth (Stand C 95) for live demo of Sectona’s Modern Infrastructure Access Platform
Is Your Bank Ready for SAMA? 10 Privileged Access Gaps to Check
One privileged account. One overlooked permission. One compromised session.
That could be all it takes to put a bank’s most critical systems at risk.
Saudi banks are rapidly embracing cloud, digital banking, automation, and third-party ecosystems. But with every new system, vendor, administrator, and remote connection comes another privileged access pathways that attackers can exploit.
And here’s the uncomfortable question: “Do banks really know who has the keys to their most sensitive systems?”
In many cases, the answer is more complicated than it seems. Dormant accounts, excessive privileges, shared credentials, standing access, unmanaged service accounts, and poorly controlled third-party access can quietly create gaps in even the most mature security environments.
For Saudi financial institutions, closing these gaps is about more than preventing breaches. It is also about strengthening cyber resilience, meeting evolving regulatory expectations, and ensuring that privileged access is granted only to the right people, for the right reasons, and for exactly as long as it is needed.
The scale of regulatory enforcement also highlights the cost of getting compliance and controls wrong. Last year, CMA imposed SAR 179.1 million in penalties on 255 violators, with SAR 103.85 million, 58% of the total, successfully collected for SAMA-related violations.
So, why do these gaps occur? And where are they hiding?
Let’s take a look at the 10 privileged access gaps Saudi banks need to identify and close, before attackers find them first.
1. Orphaned and Stale Accounts
Usually, when the person responsible for an account leaves the organisation, the account is either frozen until its data is transferred or deleted immediately. In some cases, however, the account is simply forgotten and becomes orphaned. These orphaned accounts can create one of the organisation’s biggest cybersecurity data-breach risks.
The challenge is compounded by the fact that servers, databases, network devices, hypervisors, cloud consoles, SaaS admin panels, and applications may each have their own local administrator or superuser accounts. Often, no single function has complete visibility across all of them.
Over time, privileged accounts accumulate silently through infrastructure changes, migrations, and vendor onboarding. Default accounts shipped with appliances, database engines, and network equipment may also remain active, without being renamed, disabled, or adequately logged.
This is why organisations should maintain a living, automatically reconciled inventory of all privileged accounts. That inventory should be regularly cross-checked against actual system-level account lists, with a clearly assigned owner for every account and a documented process for registering new privileged accounts as soon as a new system goes live.
The reason is simple: every other control, such as vaulting, MFA, periodic access reviews, monitoring, and alerting; is only as effective as the inventory it is applied to. For a bank, the inability to produce a complete and defensible list of privileged accounts can itself become a significant audit and regulatory finding, regardless of how sophisticated its PAM tooling may be.
2. Unmonitored Third-Party Vendor Access
Third-party vendor access is one of the highest cybersecurity risks facing the financial sector. Yet it is often underestimated because organisations assume that vendors have limited access and therefore represent a limited threat. In reality, even a small number of privileged or remote vendor accounts can provide a direct pathway into critical systems, making third-party access one of the most overlooked; and most consequential, areas of cybersecurity risk.
The risk becomes even more significant from a governance and regulatory perspective. SAMA Domain 3.4 requires organisations to incorporate cybersecurity obligations into their vendor contracts. However, many organisations rely on brief or generic security clauses that do not adequately define the vendor’s cybersecurity responsibilities, access controls, incident-notification obligations, audit rights, data-protection requirements, and accountability.
The situation can become particularly challenging with foreign vendors, who may be unwilling to accept SAMA-specific contractual requirements. If these requirements are not addressed during vendor onboarding and contract negotiations, organisations can face significant legal, regulatory, and operational challenges later; particularly when a security incident occurs.
Third-party risk, therefore, cannot be treated simply as a procurement or vendor-management issue. Organisations need a structured process to identify every form of vendor access, assign ownership, enforce least privilege, review access periodically, and ensure that appropriate cybersecurity obligations are contractually binding from the outset.
Because when a third party has access to your environment, their security posture becomes part of your security boundary.
Also Read: The Hidden Backdoor in Your Supply Chain: Third-Party Access under NIS2
3. Authentication Priorities for Administrative Interfaces
Banks under SAMA’s supervision have predefined guidelines that prioritise many authentication principles:
- Risk-based Authentication:
Transaction and account access should have layers of authentication depending on their risk factors. For example, high-value transactions, beneficiary additions, and sensitive configure changes requires stronger authentication compared to balance inquiries. - Multi-factor Requirements:
Along with the One-time password (OTP), SAMA has put licensing conditions for banks and payment providers to specify multi-factor authentication (MFA) where at least one factor resides on a registered device. This allows institutes towards app-based authenticators and biometric verification rather than relying on OTPs. - Transaction Sightings:
SAMA encourages a cryptic transaction signing for payment authorisation, where the user has to verify and approve specific transaction detail rather than generic OTP. This helps preventing attackers from reusing intercepted codes for unauthorised transactions. - Fraud Monitoring Integration:
When it comes to authentication decisions, it should include real-life fraud signals, such as device fingerprinting, behavioural analytics, and geolocation checks. Banks should not rely solely on OTPs or the knowledge factors without contextual fraud detection, as it may leave the institute vulnerable to sophisticated and planned account takeover.
4. Shared and Non-Personal Privileged Accounts Without Individual Accountability
During audits, it is common to find generic accounts such as admin, root, or sa being shared among multiple engineers, DBAs, or support staff. These accounts may have no check-in/check-out process, no session-level attribution, and passwords that have remained unchanged for months, or even years.
SAMA Clause 3.3.5.4f.4 specifically addresses non-personal privileged accounts, requiring their use to be restricted, monitored, kept confidential, and supported by frequent password rotation, including rotation after each session.
The challenge is that shared accounts are often operationally convenient, particularly in legacy systems, break-glass scenarios, and service accounts used to run batch jobs. However, rotating a password after every use can be disruptive when systems and operational processes were never designed for that model. Over time, the control becomes difficult to enforce consistently, and organisations revert to static credentials.
The objective, therefore, should not simply be to eliminate every shared account; because some systems technically require them, but to ensure that every privileged action remains traceable to a specific individual.
A practical way to achieve this is to place shared privileged accounts behind a PAM solution that controls access through check-in/check-out workflows, automatically rotates the underlying password after each session, and records who requested access, which account was used, when access was granted, and what activity occurred during the session.
This preserves the operational necessity of non-personal accounts while maintaining individual accountability, credential confidentiality, and auditability.
5. Too Many Over-Privileged Service Accounts
One of the many issues an assessment can expose is the sheer numbers of users holding the standing administrative privileges. Overtime, administrators accumulate access to servers, database, network devices, cloud platforms, and applications. Initially, some of these privileges were justified or needed, but over the period, they are no longer necessary.
The problem is not the number of privileges an account has, it is how long these privileges remained active. Permanent administrative access can create opportunities for the attack surface and insider risks.
SAMA’s framework requires access to be aligned with business requirements and the principle of need-to-have or need-to-know. In simple ways, it is known as the restricted allocation and use of privileged access.
What banks should look for:
- Implement Authentication and Authorisation controls
- Provide access certification reports proving control 3.3.5 effectiveness
- Adopt the principle of least privilege by granting users only the required access
- Conduct regular access reviews and implement MFA for sensitive systems and applications
Also Read: Turkey’s Cybersecurity Law No. 7545: What Businesses Need to Know
6. Absent Session Recording and Auditing
Having a recorded session is critical in a financial sector. In case of data breach, cyberattack, or credential misuse, a recorded session can be extremely helpful. Even though it is essential, many banks cannot show exactly what a privileged user did after logging in. They do not have any session recording, no keystroke or command logging, and no real-time alerts for anomalous administrative activities.
With SAMA compliance, it is automatically assumed that this kind of visibility exists as a baseline. With Privileged Access Management, session recording is often the last piece of a PAM rollout that is implemented after vaulting and MFA.
Recorded and searchable privileged sessions across the system that’s been continuously fed into the bank’s SIEM can easily trigger real-time alerts if any anomalies are spotted. Without this, the bank has no way to identify and detect misuse in progress and cannot spot the exact pattern of what happened after an incident.
7. Infrequent Access Certifications
Most banks have access-certification cycles defined in policy, but the challenge is ensuring that these controls operate effectively in practice. During audits, it is not uncommon to find that reviews exist on paper but lack the evidence needed to demonstrate that they were actually performed. There may be no reviewer sign-off, no record of who reviewed the access, and no evidence that accounts flagged for removal were ever acted upon.
Regardless of the organisation’s size, it is also common to find active privileged accounts belonging to individuals who are no longer associated with the organisation. One reason is that line managers may not fully understand the level of access a particular privileged entitlement provides, making it difficult for them to make informed certification decisions.
The solution is to implement a workflow-driven access certification process that captures the reviewer’s identity, decision, and timestamp for every review. More importantly, the process should not end when an account is marked for removal.
The workflow should automatically verify that every access removal decision is executed within a defined SLA, with exceptions escalated when actions remain pending beyond the permitted timeframe. This creates a closed-loop process; from review and decision to remediation and verification, rather than treating access certification as a periodic compliance exercise.
Ultimately, the goal is not simply to prove that a review took place, but to demonstrate that every decision resulted in the appropriate action and that the action was completed within the required timeframe.
8. Inadequate Centralised Credential Vaulting
Most financial institutions have their passwords saved in more traditional ways, such as in spreadsheets, password-protected documents, configuration files, CI/CD pipeline scripts, or simply the person remembering it instead of having it stored in a centralised, encrypted vault with automated rotation.
This gap corelates directly with weak, reused, or long-unchanged credentials sitting on the most sensitive systems in the environment.
It happens because vaulting solutions often require upfront integration work across every system type in the institute. Additionally, hardcoded credentials in scripts and automation jobs are treated as “too risky” once they are in production, so they persist indefinitely.
Thus, every institute should have their privileged credential stored in a centralised vault with encryption that has automated rotation on a defined schedule. Additionally, no privilege password should be typed by a human during normal operations. Service account and application credentials embedded in scripts or configurations should be replaced with dynamic, vault-issued secrets wherever it is technically feasible.
Also Read: Satellite Vaulting: The Benefits of Distributed Credential Management
9. No Restriction on Concurrent Sessions or Contextual Access Policies
Another high-risk practice is allowing the same privileged credential to be used simultaneously from multiple locations or devices without controls to prevent or detect such behaviour. The risk becomes even greater when session policies do not vary based on the device, location, or time of access.
Privileged access security is not only about who has access, but also about how, when, and from where that access is being used. Attackers increasingly look for weaknesses in these contextual controls, particularly where shared or compromised credentials can be used without restriction.
Financial institutions should therefore implement session policies that restrict or prevent concurrent logons for a single privileged identity, apply additional scrutiny to access attempts from unexpected devices or locations, and generate alerts when privileged access occurs outside established working patterns.
These controls are particularly valuable for detecting and preventing shared-credential misuse. When combined with strong authentication, PAM, and session monitoring, they create an additional layer of protection by ensuring that even a valid privileged credential cannot be used freely from multiple locations, devices, or unusual time periods.
10. Weak Deprovisioning When Roles Change or Employment Ends
Privileged access is often granted for a specific project, role, or temporary assignment, but the access is not always revoked when the business need ends. This can happen when an employee changes roles, is transferred to another department, or leaves the organisation altogether.
While this issue is connected to the access-review gap discussed earlier, assessors typically view it as a separate control weakness. The problem is not simply that a periodic review was missed; it indicates that the organisation’s Joiners-Movers-Leavers (JML) process is not effectively triggering the required access changes.
A strong JML process should therefore be automated, with events from the HR system of record directly triggering changes in the identity and access-management environment. Privileged access should be explicitly identified within this workflow and subject to immediate review, suspension, or removal when a role changes or employment ends, reflecting the higher risk associated with elevated privileges.
The objective is to ensure that access does not remain active simply because someone forgot to remove it during a periodic review. The moment a person’s employment status or role changes, the access lifecycle should change with it.
Also Read: An Overview of SAMA Cybersecurity Framework
Don’t Wait for the Assessment to Find the Gap
A SAMA assessment shouldn’t be the moment a bank discovers that privileged access is too broad, too permanent, or too difficult to monitor. It should be the point at which a mature security program demonstrates that these risks have already been identified and addressed.
For Saudi banks, closing privileged access gaps is about more than checking compliance requirements. It means knowing who has privileged access, why they have it, when they can use it, what they can do, and whether every action can be traced back to an individual.
The banks that stay ahead will be the ones that treat privileged access as a continuous security discipline rather than a point-in-time compliance exercise.
Because the goal isn’t to pass the next SAMA assessment, it is to make sure there are fewer gaps for the assessment to find in the first place.
Schedule a demo with us to learn more about SAMA compliance and how we can help you with it.
FAQs
Conduct a regulatory gap assessment, establish governance and compliance controls, develop policies/SOPs, train employees, monitor controls, and perform regular audits and remediation.
For Saudi operations, key areas include AML/KYC, governance, risk management, internal controls, customer protection, cybersecurity, reporting, and audit.
There is no standard SAMA certification timeline. Implementation typically takes 2–18+ months, depending on the institution's size, complexity, and compliance maturity.
SOPs translate SAMA requirements into clear, repeatable processes by defining responsibilities, controls, approvals, documentation, monitoring, and escalation procedures.
The institution may receive findings and remediation requirements. Depending on severity, SAMA may impose warnings, fines, increased supervision, activity restrictions, or other regulatory action.
They are separate regulatory frameworks. SAMA covers financial-sector regulation, while ZATCA covers tax, zakat, customs, and e-invoicing. A Saudi financial institution may need to comply with both.
Recent Posts
