IAM and PAM FAQs: Privileged Access, Machine Identities, AI Agents, and SAP Explained

Identity has become one of the most important control points in enterprise security. As IT landscapes extend into the cloud, and as automation and AI agents take on work once done by people, the number of identities with meaningful access keeps growing, and so does the cost of getting access wrong. This FAQ answers 20 common questions about IAM and PAM, from least privilege and emergency access to machine identities, AI agents, and how SAP-native tools fit into the wider architecture.

1. What’s the difference between IAM, IGA, and PAM?

Identity and Access Management is the broad discipline of identifying users and other entities, authenticating them, and controlling what they can access. Identity Governance and Administration adds the processes that decide whether access is appropriate, including requests, approvals, provisioning, access reviews, role management, and evidence. Privileged Access Management applies stronger controls to identities and access paths that could cause significant harm if misused.

In an SAP environment, SAP Cloud Identity Services can support authentication, federation, and provisioning, while SAP Cloud Identity Access Governance and SAP Access Control provide governance capabilities for areas such as access requests, certification, risk analysis, and emergency access. An enterprise PAM platform may govern administrative access across SAP, databases, operating systems, cloud platforms, and other infrastructure. These capabilities overlap at their edges, but they are not interchangeable.

2. What counts as a privileged identity, and why does privilege extend beyond administrator accounts?

A privileged identity is any human or non-human identity whose access could materially affect systems, data, security controls, or business processes. Domain administrators and SAP Basis administrators are obvious examples, but privilege can also sit with application support teams, database administrators, integration users, batch accounts, robotic process automation, and services that can post transactions or change sensitive master data.

The useful test is business impact, not the account label. A user who can create a supplier and release a payment may present more business risk than a technically named administrator with tightly limited duties. Similarly, a technical account used by an interface may be privileged if it can process high-value transactions at scale. PAM scope should therefore follow sensitive actions and access paths, not just accounts containing “admin” in their names.

3. What’s the difference between RBAC and ABAC?

Role-based access control (RBAC) grants permissions through defined roles, such as accounts payable analyst or SAP security administrator. Attribute-based access control (ABAC) evaluates policies against attributes of the requester, resource, requested action, and environment. Those attributes might include department, employment type, data classification, device health, location, or time of access.

Most large organizations need both. SAP business and technical roles provide a manageable RBAC foundation, while contextual policies can apply additional conditions before access is allowed. For example, a user may hold an eligible administrative role, but activation may still require a managed device, strong authentication, an approved change window, and a valid support ticket. ABAC does not remove the need for sound role design, and RBAC alone may be too static for higher-risk access decisions.

4. What is the joiner-mover-leaver process, and why does access accumulate when people change roles?

Joiner-mover-leaver processes create access when someone joins, adjust it when responsibilities change, and remove it when the relationship ends. The mover stage is difficult because adding new access is usually necessary for the person to start work, while removing old access requires an accurate view of what is no longer needed. The problem is magnified when identity data, application ownership, and provisioning are fragmented.

A reliable mover process needs event-driven updates, clear role mappings, explicit removal rules, and targeted review of accumulated access. It should also cover contractors, suppliers, and technical identities whose sponsors or purposes change.

5. What does a reasonable access request and approval workflow look like?

A good workflow collects enough information to support a defensible decision without routing every request through a long chain of approvers. It should identify the requester, business purpose, requested entitlement, target system, required duration, data or process sensitivity, and any segregation of duties or policy conflicts. Standard, low-risk access can follow a streamlined path. Sensitive or exceptional access needs stronger scrutiny.

The manager can confirm the person’s job need, but the application, role, or business-process owner is usually better placed to judge what the access permits. Automated policy and segregation of duties checks should inform the decision before provisioning. Security should be involved when a request creates an exception, not used as a substitute for accountable ownership.

In SAP Access Control, for example, workflows can expose risk-analysis results to approvers. The completed record should show what was requested, why it was approved, who approved it, when it expires, and whether provisioning succeeded.

6. How often should access be certified, and who is qualified to make the decision?

NIST (National Institute of Standards and Technology) leaves review frequency to the organization because it should reflect risk, regulatory obligations, rate of change, and the sensitivity of the access. High-impact administrative roles, emergency access, and access to sensitive financial processes may need more frequent review than stable, low-risk entitlements. Reviews should also be triggered by events such as a role change, acquisition, control failure, or change in system ownership.

The reviewer must understand what the access enables. Managers can confirm whether a person still works in a function, but role owners, application owners, and business-process owners are often better qualified to validate specialist permissions.

SAP user access reviews can be routed to managers or role owners, while Firefighter activity requires separate review by the appropriate controller. Review quality matters more than calendar frequency. A quarterly rubber stamp provides less assurance than a focused, evidence-led review.

7. How do you discover and prioritize privileged identities and access paths across a hybrid estate?

Moving to a hybrid estate is complex and brings with it a whole set of privileged identity and access challenges to consider. Start with the systems and processes whose compromise would have the greatest business effect, then identify every route through which privileged action can occur. That includes named administrators, shared or emergency accounts, service accounts, nested group membership, cloud roles, API credentials, database access, remote support tools, and the systems that can reset or provision those privileges.

Prioritization should consider privilege level, credential exposure, standing access, external reachability, usage, ownership, and whether activity is logged. This prevents a PAM rollout from securing the most obvious accounts while leaving an easier route to the same assets unmanaged.

SAP discovery should extend beyond visible application roles. It may need to cover Firefighter IDs, powerful technical users, RFC and integration accounts, SAP BTP role collections, database administrators, operating-system access, and corporate identity administrators who can influence SAP authentication.

Discovering new SAP credential and account types especially SAP BTP credentials can be challenging given they are often created deep within the system. This can be accelerated through adoption of AI lead tooling specializing in access and governance and discovery of new credential types that can integrate with PAM as system of record.

8. What’s the difference between standing access, just-in-time access, and just-enough access?

Standing access remains available whether or not it is being used. Just-in-time (JIT) access activates privilege only for an approved period or task. Just-enough access (JEA) limits the permitted actions to what the task requires. The controls address different dimensions of least privilege: JIT reduces duration, while JEA reduces scope. Zero standing privilege (ZSP) aims to eliminate persistent privileged access altogether, using controls such as JIT and JEA to grant narrowly scoped access only when it is needed.

SAP Firefighter and SAP Cloud Identity Access Governance privileged-access workflows can support time-bound emergency access scenarios, while enterprise PAM can extend JIT, JEA, and ZSP controls to operating systems, databases, cloud consoles, and other components around SAP. Some emergency and service accounts may require standing capability, but those exceptions should be deliberately limited and closely monitored.

9. What authentication and endpoint controls should protect privileged access?

Privileged access should use phishing-resistant multi-factor authentication wherever the technology supports it. NIST identifies cryptographic authentication as the basis of phishing resistance. Passkeys, FIDO2 security keys, and certificate-based authentication can provide stronger protection than methods based on SMS, voice calls, or manually entered one-time codes.

Authentication is not enough if the session begins on a compromised device. But you can reduce risk exposure by using separate administrative identities, managed privileged workstations, device-health checks, restricted administrative interfaces, and limited browsing or email use.

For SAP cloud applications, authentication may be delegated through SAP Identity Authentication to the corporate identity provider, where strong authentication and conditional-access policies are enforced.

10. How does break-glass or emergency access work, and how should it be audited afterward?

Break-glass access is a deliberately exceptional route used when normal administrative controls are unavailable or would prevent urgent recovery. It should rely on a very small number of tightly protected accounts or procedures, use authentication that does not share the same failure dependencies as the normal route, and generate immediate alerts when invoked. The access should be tested periodically so that it works when needed.

Every use needs a documented reason, a named individual, a defined start and end, detailed activity logging, and prompt independent review. Credentials should be changed or invalidated when the design and credential type require it, particularly after a shared emergency credential is exposed or used.

In an SAP estate, Firefighter may provide governed emergency access for SAP S/4HANA and SAP ERP while SAP Access Control remains available. It is essential to extend break-glass principles to SAP cloud, too, including SAP BTP and SaaS solutions by leveraging PAM solutions and using detective and preventative controls to monitor uplifted account access.

Because Firefighter depends on Access Control, organizations also need a documented fallback for when Access Control itself is unavailable, such as a tightly restricted emergency user in the target system in which credentials are vaulted, use triggers an immediate alert, and activity is reconciled against the SAP Security Audit Log afterward.

11. How should privileged access for suppliers, consultants, and other third parties be controlled?

Third-party access should use named identities, an accountable internal sponsor, explicit system and task scope, strong authentication, and an expiry aligned with the contract or support window. Keeping dormant supplier accounts enabled “just in case” turns a commercial relationship into standing technical exposure. Shared vendor accounts also weaken accountability.

For SAP support, a consultancy may need temporary access to an application, database, operating system, or cloud service. The route should grant only the required layer, ideally through JIT activation and a monitored administrative path. Session and change evidence should be retained, and access should be removed automatically when the approved window or engagement ends. The organization should also review technical accounts installed by third-party tools, because those identities can remain privileged long after the original implementation team has left.

12. When should privileged credentials be rotated?

There is no single rotation schedule that suits every privileged credential. Frequency should reflect the level of access, the likelihood of exposure, regulatory requirements, how the credential is used, and the potential impact of compromise. Credentials should also be rotated promptly after suspected exposure, personnel or ownership changes, emergency use, or another event that calls their integrity into question.

Rotation is only one part of credential security. Organizations should control how privileged credentials are issued, stored, used, monitored, and revoked. Where possible, short-lived credentials and managed identities can reduce reliance on long-lived secrets.

In SAP environments, the policy should cover administrative accounts, emergency access, technical users, integrations, and the credentials used across the supporting infrastructure. Any rotation process should account for system dependencies such as connected downstream systems so that improving security does not inadvertently interrupt business operations. For example, changing a service account password may interrupt an application that uses it to connect to a database unless the credential is updated in both places through a coordinated, tested process.

13. How should IAM and PAM support continuous monitoring and identity threat detection and response?

IAM and PAM should give security teams both visibility into identity activity and the means to act when something suspicious occurs. This is becoming increasingly important with the rise of autonomous identities, including agents that can access systems and take actions without direct human involvement.

IAM can provide events such as unusual sign-ins, failed authentication, role changes, new account creation, and access granted outside the normal approval process. PAM can enforce controls over privilege elevation, credential use, administrative sessions, commands, and access to sensitive systems, while also recording the resulting activity. Feeding these events into security monitoring or identity threat detection and response (ITDR) tools helps teams identify activity that would be difficult to recognize from isolated logs.

14. What’s the difference between a service account, a workload or machine identity, and an AI agent identity?

A service account is an account used by an application, service, script, or scheduled process rather than a person. A workload or machine identity is a broader concept: it represents software, a device, a container, a cloud workload, or another computing component and may authenticate through a certificate, token, key pair, or platform-issued identity rather than a conventional account and password.

An AI agent identity belongs to software that can select and sequence actions, use tools, and act with a degree of autonomy. It still needs a verifiable identity, but its authority may be delegated by a person or another system and may change from one task to the next.

In SAP environments, the relevant population can include batch users, communication users, integration services, bots, and agents that call SAP APIs.

15. Why do non-human identities now outnumber human identities in many enterprises?

One employee usually has a limited number of workforce identities, but a single digital service can create several machine identities, tokens, certificates, and integration credentials across development, test, and production. Cloud platforms, microservices, SaaS integrations, automation, and CI/CD pipelines multiply that population further. AI agents add another layer because each agent, tool connector, and delegated task may require its own identity or credential.

In a hybrid SAP estate, technical users, communication arrangements, APIs, middleware, cloud services, and automation can create a large identity population that is not tied to the HR processes used for employees.

16. What’s the difference between traditional PAM and PAM for machine identities?

Traditional PAM grew around human administrators and shared high-value accounts. Its common controls include credential vaulting, password rotation, access requests, session brokering, command or session recording, and time-bound elevation. Those controls remain important, but machine identities operate differently. They authenticate continuously, at high volume, through APIs and automated workflows, and often cannot pause for an interactive approval or credential checkout.

PAM for machine identities therefore puts greater weight on automated discovery, identity ownership, secret and certificate lifecycle, workload attestation, short-lived credentials, policy enforcement at runtime, and integration with development and cloud platforms. It must also understand dependencies so that rotation or revocation does not break workflow. Organizations do not necessarily need two unrelated PAM programs. They do need controls that account for both human sessions and machine-to-machine access, including SAP interfaces and technical users.

17. What should a non-human identity inventory contain, who should own each identity, and how should its lifecycle be managed?

An inventory should record a unique identifier, identity type, business purpose, human owner or sponsor, technical custodian, target systems, permissions, environment, credential type and location, creation date, expiry, last use, dependencies, and review status. It should also show how the identity is created, changed, disabled, and recovered during an incident.

Ownership must sit with someone who can judge whether the identity still serves a valid purpose and accept accountability for its access. When an owner changes role or leaves, ownership should be reassigned rather than allowing the identity to become orphaned.

In SAP, this process should include technical and communication users, interfaces, bots, and integration credentials.

18. How do you apply least privilege, accountability, and runtime controls to an autonomous AI agent?

Give each agent a distinct identity and do not let it inherit a person’s full session or share a general-purpose service account. Scope access to the specific tools, resources, data, and actions required for the task. Where the agent acts on someone’s behalf, preserve the delegation chain so that systems can distinguish the agent, the sponsoring user, and the authority granted for that action.

Static provisioning is only the starting point. High-impact actions, such as changing access, releasing a payment, deleting data, or modifying production, should be checked by an independent policy-enforcement point and may require step-up authentication or human approval. Lower-risk actions can be automated within defined boundaries. Log tool calls, parameters, approvals, and outcomes, monitor for abnormal behavior, and provide a rapid way to revoke credentials or stop the agent.

19. Do SAP Cloud Identity Services and SAP Cloud IAG replace enterprise IAM and PAM platforms, or work alongside them?

They often work alongside them. SAP Cloud Identity Services includes capabilities for authentication, identity federation, provisioning, and identity data. SAP Identity Authentication can act as an identity provider or proxy authentication to a corporate identity provider, while Identity Provisioning synchronizes users and groups between source and target systems. SAP Cloud Identity Access Governance provides services for access requests, certification, access analysis, role design, and privileged access.

Those capabilities do not automatically replace an enterprise identity provider, IGA platform, or PAM service that governs the wider technology estate. SAP documentation supports integration with corporate identity providers and other identity-management systems, including standards-based provisioning scenarios. The right division of responsibility depends on application coverage, SAP-specific risk analysis, connectors, workflow ownership, deployment model, and existing investment.

20. How does SAP Firefighter relate to enterprise PAM?

SAP Firefighter is the emergency access capability within SAP Access Control’s Emergency Access Management. It allows authorized users to obtain elevated SAP access through Firefighter IDs or roles, with defined owners, controllers, reasons, activity logs, and post-use review. It addresses a specific SAP application-governance need.

Enterprise PAM usually covers a wider set of privileged access paths, including operating systems, databases, network devices, cloud consoles, and administrative credentials across SAP and non-SAP systems. The two can complement each other. Firefighter can provide the SAP transaction and business-process context, while enterprise PAM can protect credentials, broker sessions, or monitor the surrounding infrastructure. The operating model should align identities, approval windows, ownership, and evidence, and it should avoid parallel emergency routes that are governed differently.