HR as the single source
Hires, transfers and terminations flow from the HR system to IAM in near real time. The employee number becomes the key that links every account a person holds.
IAM and PAM implementation
Implement IAM and PAM across the access lifecycle.
Limaz designs and deploys identity and privileged-access controls around real joiner, mover, leaver, administrator, vendor, and review workflows.
Identity controls fail between systems
Buying an IAM or PAM platform does not define who should approve access, how roles are designed, what happens to exceptions, or how access is removed when people and responsibilities change.
Limaz connects identity sources, business applications, privileged accounts, workflows, and evidence so access decisions can be made, enforced, reviewed, and explained.
Implementation scope
- Identity lifecycle
- Joiner, mover, leaver, contractor, and service-account processes with clear system ownership.
- Access model
- Roles, entitlements, segregation-of-duties rules, birthright access, and exception paths.
- Requests and approvals
- Business-readable access requests, accountable approvals, fulfillment, expiry, and revocation.
- Access reviews
- Campaign design, reviewer context, escalation, remediation, and auditable completion.
- Privileged access
- Discovery, vaulting, credential rotation, session control, recording, break-glass, and vendor access.
- Integration
- HR sources, directories, cloud platforms, business applications, ticketing, SIEM, and selected IAM/PAM products.
- Operational handover
- Runbooks, ownership, support boundaries, evidence, and measures for ongoing operation.
IAM vs PAM
Identity and access management (IAM) governs every identity in your organisation: employees, contractors, vendors and service accounts. It answers three questions. Who is this, what should they reach, and who approved it?
Privileged access management (PAM) protects the accounts with administrative power: domain and database administrators, root on servers, firewall and cloud console administrators, and the service accounts behind core banking, lending and payment systems. These accounts can change data, switch off logging and create new accounts. They need tighter controls: vaulted credentials, approved and time-bound sessions, and recorded activity.
Regulators treat the two separately. The National Cybersecurity Authority (NCA) Essential Cybersecurity Controls (ECC-2:2024) list privileged access management as its own requirement in control 2-2-3, next to multi-factor authentication, least privilege and periodic access review. The Saudi Central Bank (SAMA) Cyber Security Framework (CSF) sets out privileged and remote access management as a distinct item in section 3.3.5 Identity and Access Management.
You need both. IAM keeps the everyday access model correct. PAM protects the small set of accounts that could do the most damage in a single session.
The access lifecycle: joiner, mover, leaver
Most access findings trace back to one broken lifecycle step. We build each step as an automated flow triggered by the human resources (HR) system, because SAMA CSF 3.3.5 expects job changes for staff to be instigated by HR.
Joiner
HR creates the worker record. The IAM platform creates the directory account and grants birthright access for the role: email, intranet and the applications that role always needs. Anything beyond that goes through a request with a named approver.
Request and approval
Users request extra access from a catalogue written in business language. The request goes to the application or data owner, the approval is recorded, only the approved access is provisioned, and temporary access gets an expiry date. This is what Payment Card Industry Data Security Standard (PCI DSS) requirement 8.2.4 expects: changes authorised with approval and implemented with only the approved privileges.
Mover
A transfer or promotion in HR triggers a recalculation. Access for the new role is added. Access tied to the old role is removed or sent to the new manager to confirm within a fixed window. This step stops privilege build-up, the most common finding in access reviews.
Leaver
Termination in HR disables the directory account, ends single sign-on sessions, removes application access and rotates any shared credential the person knew. NCA ECC control 1-9-5 requires access to be revoked immediately when employment ends, and PCI DSS requirement 8.2.5 requires immediate revocation for terminated users.
Contractors, dormant and service accounts
Contractor and vendor accounts carry an end date from day one. Accounts inactive for 90 days are disabled, the limit in PCI DSS requirement 8.2.6. Every service account has a named owner and is reviewed like a person.
Privileged access controls that regulators check
- Inventory of privileged accounts
- A complete list of administrator, root, database, network, cloud and application super-user accounts, each with an owner. Examiners start here and test whether the list matches what exists on the systems.
- Individual accountability
- Every privileged action traces to a named person. SAMA CSF 3.3.5 calls for individual accountability for privileged use. PCI DSS requirement 8.2.2 allows shared or generic accounts only by exception, with management approval and every action attributable to an individual.
- Vaulting and rotation
- Shared and built-in administrator passwords live in a vault and are checked out per session. SAMA CSF expects passwords of non-personal privileged accounts to change frequently and at the end of each session. PCI DSS requirement 8.6.2 bans hard-coded passwords for system and application accounts in scripts, configuration files and source code.
- MFA for privileged and remote access
- NCA ECC control 2-2-3 requires multi-factor authentication (MFA) for privileged accounts and remote access. PCI DSS requirement 8.4.1 requires it for all non-console administrative access into the cardholder data environment (CDE).
- Least privilege and segregation of duties
- Administrators hold rights for their own platform only, with just-in-time elevation for high-risk tasks. ECC control 2-2-3 names need-to-know, need-to-use, least privilege and segregation of duties as the principles for authorisation.
- Session recording and logs
- Privileged sessions are recorded and their events flow to the security information and event management (SIEM) platform. ECC control 2-12-3 requires event logs for critical and privileged accounts and for remote access, kept for at least 12 months.
- Break-glass access
- Emergency accounts are sealed in the vault, used only under a documented procedure, raise an alert on every use and are rotated after each use.
Access reviews that actually happen
Every framework asks for periodic access review. PCI DSS requirement 7.2.4 is the most specific: review all user accounts and their privileges, including third-party and vendor accounts, at least once every six months, fix inappropriate access, and have management confirm that the remaining access is appropriate. Requirement 7.2.5.1 adds periodic review of application and system accounts, at a frequency set by a targeted risk analysis.
Reviews fail for predictable reasons. Managers receive a spreadsheet of cryptic entitlement names, approve everything, and nobody checks that removals happened. The campaign shows as complete, access stays the same, and auditors see through it.
We design reviews that reviewers can answer. Each entitlement carries a plain description and a risk rating. Reviewers see what changed since the last cycle plus all high-risk access. Every revocation opens a ticket automatically, and the campaign closes only when the target systems confirm removal. The evidence pack shows the population reviewed, each decision, each revocation and management sign-off.
Review privileged accounts, vendor accounts and access to customer or card data more often than standard user access.
MFA and SSO
- NCA ECC
- MFA for remote access and for privileged accounts, with the number and type of factors chosen from an impact assessment of authentication failure and bypass (control 2-2-3). ECC also requires MFA for remote and webmail access to email (control 2-4-3).
- SAMA CSF
- MFA for sensitive and critical systems and profiles, and for all remote access (section 3.3.5).
- PCI DSS v4.0.1
- MFA for all non-console administrative access into the CDE (8.4.1), for all access into the CDE (8.4.2, mandatory since 31 March 2025), and for all remote network access from outside the entity's network that could reach or affect the CDE, including vendors (8.4.3).
- What good MFA looks like
- PCI DSS requirement 8.5.1 sets the bar: resistant to replay attacks, no bypass except a documented and time-limited management exception, at least two different factor types, and every factor must succeed before access is granted.
- Single sign-on (SSO)
- SSO through SAML 2.0 or OpenID Connect puts every application behind one identity provider. MFA and conditional access rules apply in one place, and disabling the directory account closes access to every connected application at once.
- Legacy applications
- Systems without SAML or OpenID Connect support sit behind the PAM gateway or an access proxy, so they still inherit MFA and session logging.
Integration with HR, AD/Entra and core systems
IAM is only as strong as its connections. These are the integrations we build and test.
Active Directory and Microsoft Entra ID
On-premises Active Directory (AD) and Microsoft Entra ID are provisioned from IAM. Group structures are cleaned up and mapped to roles, and hybrid sync is set so a leaver is disabled in both.
Core banking, lending and payments
Many core systems keep their own user tables. We connect them through SCIM (System for Cross-domain Identity Management), APIs or database connectors. Where none exists, a controlled ticket with confirmation evidence closes the loop.
Cloud and SaaS
Cloud consoles and software-as-a-service (SaaS) applications connect through SSO and SCIM, so roles and removals stay in sync.
Ticketing and SIEM
Requests and approvals run in your IT service management tool. Authentication, provisioning and privileged session events go to the SIEM for monitoring and investigations.
Common gaps we find
- Leavers disabled in Active Directory but still active in core banking, payment or SaaS applications that use local accounts.
- Privileged accounts on servers and databases that sit outside the PAM vault.
- Service accounts with interactive login, no owner and passwords unchanged since creation.
- Hard-coded credentials in scripts, deployment pipelines and configuration files.
- MFA on the virtual private network (VPN) but missing on cloud consoles, admin portals and vendor remote access.
- Access reviews signed off with no evidence that revocations were carried out.
- Roles that grow by copying a colleague's access instead of following a defined role model.
- Break-glass accounts with no alerting and passwords known to several administrators.
Related security work
Security control implementation
The broader implementation service around enterprise security controls.
DevSecOps implementation
Identity, secrets, and delivery controls inside software pipelines.
Cybersecurity risk management
Prioritize access risks and treatment decisions.
NCA ECC & CCC implementation
Connect access-control work to applicable NCA controls.
Questions
Identity and access management (IAM) controls every identity and what it can reach: employees, contractors, vendors and service accounts. Privileged access management (PAM) is the part of IAM that protects administrator, root, database and other high-power accounts. PAM adds a credential vault, password rotation, approved and time-bound sessions, and session recording. NCA ECC and SAMA CSF both list privileged access as a separate requirement, so regulated entities in Saudi Arabia need both.
Subdomain 2-2 of the Essential Cybersecurity Controls (ECC-2:2024) requires IAM requirements to be documented, approved and implemented. Control 2-2-3 sets the minimum: username and password authentication, multi-factor authentication for remote access and privileged accounts, authorisation based on need-to-know, need-to-use, least privilege and segregation of duties, privileged access management, and periodic review of identities and access rights. Control 2-2-4 requires the implementation to be reviewed periodically.
Yes. Section 3.3.5 Identity and Access Management of the SAMA Cyber Security Framework requires multi-factor authentication for sensitive and critical systems and profiles, and for all remote access. The same section requires HR-driven joiner, mover and leaver processes, formal approval based on need-to-have and need-to-know, periodic access reviews, an audit trail of access requests and revocations, and strict management of privileged and remote accounts.
PCI DSS v4.0.1 requires multi-factor authentication for all non-console administrative access into the cardholder data environment (requirement 8.4.1), for all access into the cardholder data environment (8.4.2, mandatory since 31 March 2025), and for all remote network access from outside the entity's network that could reach or affect it, including vendors (8.4.3). Requirement 8.5.1 adds that MFA must resist replay attacks, use two different factor types and allow no routine bypass.
PCI DSS requirement 7.2.4 sets the clearest number: review all user accounts and access privileges, including vendor accounts, at least once every six months, with management sign-off. NCA ECC and SAMA CSF require periodic review and leave the interval to the entity, so set it by risk. Review privileged accounts, vendor access and access to customer or card data more often, and keep evidence that every revocation was carried out.
Give every service account a named owner, a documented purpose and only the privileges the application needs (PCI DSS 7.2.5). Block interactive login unless an approved exception exists (8.6.1). Keep its password in a vault, never in scripts, configuration files or source code (8.6.2), and rotate it on a risk-based schedule and immediately on suspected compromise (8.6.3). Review service accounts on the same cycle as privileged users.
Yes. Many organisations already own part of the stack: Active Directory, Microsoft Entra ID, a PAM vault or an identity governance tool. Limaz starts from what you have, fixes the role model, lifecycle flows and integrations around it, and connects the systems outside it, such as core banking, lending and payment platforms. When a new product is needed, we define the requirements and deploy it against your real workflows.
Discuss your requirements with Limaz
Tell us which system, control, or requirement you are working on. We’ll come back with a clear next step.