IDM / IGA / IAM / PAM Glossary

Discipline of granting and enforcing access to resources after identity has been established. Encompasses authentication (proving who you are), authorization (deciding what you can do), session management, and access enforcement at policy enforcement points. Distinct from Identity Governance (lifecycle decisions) and from Identity Management (identity data and provisioning).

Application

MidPoint: Access Management (AM) is a security discipline that provides access to authorised users to enter particular resources.

Set of attributes, credentials, and identifiers that uniquely represent a person or non-human entity in digital systems. Combines who you are (identity proofing), what you know/have/are (authenticators), and what you can do (entitlements). NIST SP 800-63 defines digital identity as «the unique representation of a subject engaged in an online transaction».

Application

MidPoint: Digital representation of identity: set of characteristics, qualities, believes and behaviors of en entity, usually represented as a set of attributes.

Sources

• NIST SP 800-63 Digital Identity Guidelines (NIST) ↗ primary source

In identity and access management, a **directory** is a specialized, often distributed, data store optimized for fast read-oriented access to structured entries about users, devices, services, and other resources. It commonly implements a hierarchical namespace and standardized protocols (such as X.500 or LDAP) to provide query, search, and lookup functions for authentication, authorization, and configuration. In security standards, the capitalized term **Directory** frequently refers specifically to an X.500-conformant directory service.

Anything that can be assigned a digital identity and act in systems — humans, service accounts, API clients, AI agents, workloads, IoT devices, organizations. Broader than «user» (which typically implies human). Used in identity standards (SAML, OAuth, NIST SP 800-63) to refer to any actor.

Application

MidPoint: Being (such as person or animal), thing, concept or anything else that has recognizably distinct existence.

Unique representation of an entity (human, service, workload, agent) in digital systems, distinct from account (which is the system-specific access record). One identity may have many accounts across systems. ISO/IEC 24760-1: «set of attributes related to an entity». Foundational concept underlying IDM, IGA, PAM, CIAM.

Application

MidPoint: The fact of being who or what a person or thing is.

SailPoint: Identity Cube — the central identity object in IdentityIQ aggregating attributes from authoritative sources

Umbrella discipline covering identity creation/management, authentication, authorization, and audit across an organization. Encompasses subcategories: IDM (directory + provisioning), IGA (governance + lifecycle workflows), PAM (privileged access), CIAM (customer identity), AM (access management), and emerging ITDR/ISPM (identity security).

Application

MidPoint: Identity and access management (IAM) is a field concerned with managing identities (e.g.

SailPoint: SailPoint Identity Security Cloud (ISC) — full IAM SaaS platform

Sources

• NIST SP 1800-2 (csrc.nist.gov) ↗ primary source

Identity Data Source is a system of record or repository from which identity attributes, credentials, or related identifiers about persons or entities are obtained for use by identity and access management processes. It typically acts as an authoritative or upstream source for provisioning, synchronization, and verification of identity information into IAM/IGA platforms. In enterprise architectures, common identity data sources include HR systems, directories, CRM systems, and authoritative registries that originate or maintain identity data over its lifecycle.

An identity data store is a logical or physical repository that holds digital identity attributes, identifiers, credentials, and related authorization data for users, service accounts, or devices. It typically acts as an authoritative or reference source for identity information used by IAM and IGA processes, and may be implemented using directories (for example LDAP), relational databases, or specialized identity platforms. The term is often used generically and overlaps with, but is slightly broader than, an “identity store,” by emphasizing storage and governance of the underlying identity data itself rather than only the accounts it represents.

Sources

• NIST SP 1800-2 (csrc.nist.gov) ↗ primary source

Discipline of policies, processes, and oversight ensuring identities have appropriate access — no more, no less — throughout their lifecycle. Includes access requests, approval workflows, periodic access certifications, segregation of duties, role mining, and audit reporting. Foundation for SOX, SOC 2, GDPR compliance.

Application

MidPoint: Business aspect of managing identities including business processes, rules, policies and organizational structures.

SailPoint: IdentityIQ — the IGA platform combining lifecycle + governance + provisioning

Gartner-defined category combining identity governance (policies, access reviews, compliance) with administration (provisioning, account lifecycle, role management). Core functions: connect to source systems (HR, AD, cloud, SaaS), automate joiner-mover-leaver workflows, run access certifications, detect/remediate SoD violations, generate compliance reports.

Application

MidPoint: Identity governance and administration (IGA) si a subfield of identity and access management (IAM) dealing with management and governance of identity-related information.

Stages an identity goes through from creation to termination — typically Joiner (onboarding), Mover (role change, transfer), Leaver (offboarding, archival). Each stage triggers provisioning/deprovisioning workflows across connected systems. NHI lifecycle differs: create/rotate/decommission tied to workload deployment.

Application

MidPoint: Set of identity stages from creation to its deactivation or deletion.

Sources

• NIST SP 800-63 Digital Identity Guidelines (NIST) ↗ primary source

Discipline focused on creating, storing, and maintaining digital identities and their attributes. Includes identity data model design, directory services, provisioning workflows, and account synchronization. Foundation layer underneath Identity Governance (policy/oversight) and Access Management (authentication/authorization).

Application

MidPoint: Identity Management (IDM) is a process of managing digital identities and their accesses to specific resources in the cyberspace.

SailPoint: IdentityIQ — full IAM platform (IIQ) or IdentityNow (SaaS variant Identity Security Cloud)

An **Identity Management System (IDMS)** is an integrated set of technical and organizational components that create, maintain, and use digital identities for subjects such as users, devices, or services within a domain. It typically provides centralized functions for identity lifecycle management, including identity creation, update, deprovisioning, and integration with authentication and access control services. The term is generally used as an implementation‑level synonym of an identity management capability or infrastructure rather than a formally standardized product category.

System that authenticates users and issues identity assertions (SAML responses, OIDC ID tokens) to relying parties. Central component of federated SSO — users log in once at IdP, then access multiple applications without re-authentication. Enterprise: Microsoft Entra, Okta, Ping, ForgeRock. Consumer: Google, Apple, Microsoft, Facebook.

Application

MidPoint: System that provides identity-related information to applications (known in this context as "relying party" or "service provider").

Sources

• NIST SP 800-63 Digital Identity Guidelines (NIST) ↗ primary source

Identity Register is an information system or authoritative repository that stores and maintains identity data records for identified persons, entities, or devices. It typically consolidates identifiers and associated attributes from multiple sources to support identification, authentication, and authorization processes across connected systems. The term is used generically in IAM/IGA practice and does not have a single, formally standardized definition in major security standards.

Software platform implementing Identity Management functions — directory, provisioning workflows, identity reconciliation, account synchronization. Synonymous with IDM platform. May overlap with IGA system (which adds governance workflows) or remain narrowly focused on identity data and provisioning.

Application

MidPoint: MidPoint

Identity that acts in a system — making authentication requests, accessing resources, performing operations. Used in security protocols (Kerberos, OAuth, JWT) to refer to the authenticated entity. Distinct from object/resource (the thing being acted upon). Examples: user@domain, service-account@kubernetes, did:web:identigy.com.

Application

MidPoint: An entity or identity, information about which is managed in an information system.

Sources

• NIST SP 800-63 Digital Identity Guidelines (NIST) ↗ primary source

Application or service that depends on an Identity Provider to authenticate users and provide identity assertions. In SAML: Service Provider (SP). In OIDC: Client (OAuth 2.0 client). RP must trust the IdP's identity assertions and validate them cryptographically (signature, issuer, audience, expiry).

Application

MidPoint: System that relies on other party (identity provider) to provide identity information.

Sources

• NIST SP 800-63 Digital Identity Guidelines (NIST) ↗ primary source

Baseline access granted automatically to every identity of a specific type — typically minimal access required to function: email, intranet, common collaboration tools, basic application access. Assigned via HR-driven rules during onboarding without explicit access requests. Reduces day-1 friction.

Application

MidPoint: Privileges or access granted to users based on their inherent characteristic, such as user type (employee, contractor, student).

Highly-privileged account reserved for emergency use — disaster recovery, lockout recovery, after-hours critical incidents. Strictly controlled: kept in sealed vault, checkout requires multi-party approval, every use is alerted to security team, post-use review mandatory.

Application

MidPoint: Emergency account is an account (digital identity in information system) used for emergency operations in information systems.

Sources

• NIST SP 800-53 Rev. 5 (csrc.nist.gov) ↗ primary source

Identities for service accounts, API keys, OAuth client secrets, machine certificates, workload identities (AWS IAM roles, Azure managed identities, GCP service accounts), AI agents, IoT devices — anything without a human employment lifecycle. Outnumber human identities 45:1 in typical enterprises (CyberArk 2024 research). Subject to OWASP NHI Top 10 (2025) risk catalogue.

Application

MidPoint: Non-human identity (NHI) is an identity that represents entity that is not human (physical person).

SailPoint: Service Account aggregation + custom Application onboarding for NHI types

Sources

• OWASP Non-Human Identities Top 10 (2025) ↗ primary source

Account with elevated rights to administer systems, modify configurations, access sensitive data, or bypass standard controls. Examples: domain admins, root users, cloud admin roles, service accounts with admin scope. Primary target of attackers — compromise yields lateral movement and persistence.

Application

Subject to PAM controls: vaulting, session recording, MFA enforcement, JIT access, separation from regular user accounts. Required protections per PCI DSS, HIPAA, SOX, ISO 27001 A.9, NIST SP 800-53 AC family.

Sources

• NIST SP 800-53 Rev. 5 (csrc.nist.gov) ↗ primary source

Non-human account used by applications, services, or scheduled tasks to authenticate to other systems. Common categories: database access accounts, integration accounts (SSO, federation), batch job accounts, monitoring agents. Typically have static credentials (passwords, API keys, certificates) requiring rotation.

Application

MidPoint: Service account is an account (digital identity in information system) related to a service.

SailPoint: Service Account — managed via Application Account schema; manual or correlated identity

Account credentials shared by multiple users — historically common for break-glass scenarios or systems without per-user accounts. Major audit and accountability problem: cannot determine who performed which action. Required by some legacy systems but actively eliminated in modern IAM programs.

Application

MidPoint: Shared account is an account used by several entities, such as an account used by several people.

Sources

• NIST SP 800-53 Rev. 5 (csrc.nist.gov) ↗ primary source

Generic term for non-human accounts used for system-to-system communication — synonymous with service account in many contexts. Includes service accounts, integration accounts, API accounts, automation accounts. Distinct from human user accounts in lifecycle (no JML), credential type (often API keys vs passwords), and governance model.

Application

Modern IGA platforms include NHI-specific workflows: ownership documentation, automated credential rotation, scoped permissions, usage monitoring. Per OWASP NHI Top 10 risk catalogue.

Repository of IT asset configurations and their relationships — servers, network devices, applications, services. Integrates with IDM to track which identities own which assets, drive provisioning decisions, and support incident response (impact analysis).

Application

Major vendors: ServiceNow CMDB, BMC Helix CMDB, Ivanti, ManageEngine AssetExplorer. Identity integration: asset owner mapping for access decisions, automatic provisioning based on asset ownership.

In midPoint, an infrastructure element is a **target infrastructure resource** (such as a Linux host, application server like WildFly, or database like PostgreSQL) that is connected to midPoint for the purpose of managing its configuration, accounts, or related identity data. Infrastructure elements are modeled as midPoint resources or similar objects and participate in provisioning and automation processes alongside business applications. They are scoped to the technical underlay of the identity solution rather than to end‑user business systems.

Advanced Persistent Threat (APT) — targeted, well-planned, long-term attack by professional cybercriminal groups (often state-affiliated or state-sponsored). Characteristics: stealthy persistence (months/years), kill chain (recon → initial access → lateral movement → exfiltration), advanced TTPs (zero-days, custom malware). MITRE ATT&CK maps APT group TTPs.

Sources

• NIST SP 800-160 Vol. 2 Rev. 1 (csrc.nist.gov) ↗ primary source

Availability — property of being accessible and usable on demand by an authorized entity. One of the three core information security properties (availability, integrity, confidentiality) protected by information security activities.

Sources

• ISO/IEC 27000:2018 — Information security overview ↗ primary source

Controlled Zone is a term used in cleanroom and associated controlled-environment standards to mean a defined space in which environmental conditions are controlled for a specific purpose. In ISO usage, a controlled zone may be a defined space within a cleanroom or may be achieved by a separative device located inside or outside the cleanroom.

Data Diode — solution providing physically or hardware-software-enforced unidirectional data transmission with no reverse channel. Used in environments with strict isolation requirements — industrial control systems (ICS/SCADA), critical infrastructure, military networks — to export telemetry and logs from isolated segments without risk of compromise via reverse flow.

Data Loss Prevention (DLP) — technology for detecting and preventing transmission of confidential data (personal data, trade secrets, financial information) outside the organization through web, email, messaging, USB, and print channels. Content analysis (signatures, regex, fingerprinting, ML) combined with context (sender, receiver, channel).

Database Activity Monitoring (DAM) — solutions for real-time monitoring and auditing of database queries (SQL, DDL/DML, privileged DBA access). Goals: insider threat detection, compliance reporting (PCI DSS, SOX, HIPAA), forensic investigation. Orthogonal to PAM (DBA accounts).

Digital Forensics — independent expert investigation and analysis of an information security incident to reconstruct the timeline of events, identify attackers, determine compromise methods, and collect evidence. Disciplines: disk forensics, memory forensics, network forensics, mobile forensics, cloud forensics. Chain of custody is essential for legal admissibility.

Sources

• NIST SP 800-86 — Guide to Integrating Forensic Techniques ↗ primary source

Endpoint Detection and Response (EDR) — technology for identifying signs of computer attacks on infrastructure endpoints (workstations, servers) through continuous telemetry collection (processes, network connections, registry/file changes) and behavioral analysis. Evolution of traditional antivirus toward threat hunting and automated response.

Honeypot — deliberately vulnerable resource (server, application, database) deployed in an infrastructure to distract attackers and collect telemetry on attack methods. Types: low-interaction (service emulation), high-interaction (real isolated system), honeytoken (decoy data — fake credentials, fake DB records). Network of honeypots — honeynet.

Information Security Event — identified occurrence of a system, service, or network state indicating a possible breach of information security policy, failure of safeguards, or a previously unknown situation that may be security-relevant. Security events are aggregated in SIEM platforms for subsequent analysis.

Information Security Incident — single or series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security. Unlike an InfoSec Event (any observable state change), an incident has confirmed or projected impact on confidentiality, integrity, or availability.

Sources

• ISO/IEC 27035 — Incident management ↗ primary source

Managed Detection and Response (MDR) — service model combining threat detection technology (EDR/XDR) with the expertise of security service provider analysts for 24/7 monitoring and threat response. Alternative or complement to an in-house SOC for organizations without a mature security team.

Mobile Device Management (MDM) — class of solutions for centralized management and protection of mobile devices (smartphones, tablets) in corporate environments. Functions: enrollment (BYOD/COPE), policy enforcement, remote wipe, app whitelisting, compliance monitoring. Evolution — Unified Endpoint Management (UEM): MDM + EMM + traditional client management.

Sources

• NIST SP 800-124 Rev. 2 (csrc.nist.gov) ↗ primary source

Penetration Test (Pentest) — security assessment method via simulating attacks under controlled conditions. Types: black-box (no system knowledge), white-box (full source code/documentation access), grey-box (partial information). Phases: reconnaissance → scanning → exploitation → post-exploitation → reporting.

Sources

• NIST SP 800-115 — Technical Guide to Penetration Testing ↗ primary source

Red Teaming — simulation of a realistic cyber attack on an organization by an experienced offensive team (Red Team) to test the effectiveness of defensive measures and incident response (Blue Team). Differs from a pentest: longer (weeks/months), goal-oriented, uses the full spectrum of TTPs (including social engineering, physical intrusion). Goal: measure real organizational readiness for APT attacks.

Sources

• NIST SP 800-53 Rev. 5 (csrc.nist.gov) ↗ primary source

Security Gateway — software/hardware solution installed between an organization's internal network and public networks, performing traffic filtering, packet inspection, and protection from external attacks (malware, phishing, DDoS, exploits). Combines firewall (FW/NGFW), intrusion prevention (IPS), and web filtering capabilities.

Security Information and Event Management (SIEM) — class of software solutions performing real-time collection, normalization, correlation, and analysis of security events from various sources (security tools, network devices, servers, applications). Core use cases: detection use cases (IOC matching), threat hunting, compliance reporting (GDPR, PCI DSS, HIPAA, SOC 2).

Security Operations Center (SOC) — centralized function dedicated to monitoring and responding to information security incidents, combining technology (SIEM, EDR, SOAR), processes (detection → investigation → response), and a team of analysts (Tier 1/2/3 + IR). Deployment models: in-house, hybrid, SOC-as-a-Service (SOCaaS / MSSP).

Sources

• NIST SP 800-172 (csrc.nist.gov) ↗ primary source

Threat Hunting — proactive, iterative search for indicators of malware or compromise undetected by standard detection tools (SIEM, EDR, AV). Hypothesis-driven approach: form a hypothesis (e.g., «we are compromised via ATT&CK T1078») → analyze telemetry (logs, network flows, EDR events) → confirm/refute → automate (create detection rule in SIEM).

Threat Intelligence (TI) — information about current threats, tactics, techniques, and procedures (TTPs) of cybercriminal groups, used to understand attacker methods and inform defensive measures. Levels: strategic (for CISO/Board), operational (for SOC), tactical (for analysts), technical (IOCs — hashes, IPs, domains). Platforms — Threat Intelligence Platform (TIP).

Zero-Day Vulnerability — previously unknown vulnerability in software for which no patch or protection mechanism has been developed. Zero-day exploits are particularly dangerous for targeted attacks (APT) — defenders lack signatures, fingerprints, or detection rules.

Basel II is the second set of international banking regulatory standards issued by the Basel Committee on Banking Supervision, establishing minimum capital requirements, supervisory review processes, and disclosure obligations for banks. It introduced a more risk-sensitive framework for credit, market, and operational risk, including the three-pillar structure (minimum capital, supervisory review, and market discipline). Although superseded in many jurisdictions by Basel III, its concepts still influence contemporary prudential regulation and risk management frameworks.

A detective control is a control designed to identify, detect, or discover events, conditions, or incidents after they occur or while they are in progress. In security and governance contexts, it is used to provide visibility into unauthorized activity, anomalies, or policy violations so that response actions can be triggered. The term is commonly contrasted with preventive and corrective controls, but it is not itself a formally standardized term in the major IGA/security standards cited here.

Sources

• NIST SP 800-53 Rev. 5 (csrc.nist.gov) ↗ primary source

US federal law (1999) requiring financial institutions to safeguard customer information and disclose information-sharing practices. The Safeguards Rule (updated 2023) mandates a written information security program with access controls, encryption, MFA for non-public information access, and incident response procedures. The Privacy Rule governs how financial institutions share customer data with affiliates and non-affiliated third parties.

Synonyms

• Financial Services Modernization Act

Application

Affects banks, credit unions, securities firms, insurance companies, and any business significantly engaged in financial activities. IDM/IAM impact: MFA mandatory for access to customer NPI, role-based access controls (RBAC), privileged access management (PAM) for administrative accounts, regular access reviews.

Sources

• FTC — GLBA Safeguards Rule ↗ primary source

Governance is the framework of authority, oversight, and decision-making by which an organization is directed and controlled to achieve its purpose and objectives. In an enterprise security context, governance typically sets policies, assigns accountability, and establishes how decisions are made and monitored. The term is broad; when used in standards it is often qualified by scope such as *risk governance* or *data governance*.

Governance, Risk Management and Compliance (GRC) is an umbrella term for the integrated set of capabilities that ensure an organization is directed and controlled (governance), identifies, assesses and treats uncertainty (risk management), and adheres to applicable laws, regulations and internal policies (compliance). In IAM/IGA, GRC typically refers to aligning identity controls and access decisions with enterprise risk appetite, regulatory obligations, and oversight processes. The term is widely used in industry practice but is not formally defined in major security or identity standards.

Confirmed incident where information confidentiality, integrity, or availability has been compromised. Identity-related breaches: credential theft, account takeover, privilege escalation, unauthorized access, insider data exfiltration. Subject to mandatory notification under GDPR (Art. 33-34), HIPAA Breach Notification Rule, state breach laws (US).

Application

Detection via SIEM/SOAR, ITDR, identity anomaly detection. Response: ITDR-driven containment, identity forensics, customer/regulator notification, remediation. Common identity breach root causes: phishing, password reuse, lack of MFA, over-privileged accounts.

Granting access beyond what's needed for the role — common cause of attack surface expansion and SoD violations. Sources: copy-paste provisioning (give new hire same access as predecessor without review), accumulated access from role changes, over-broad role definitions. Detected by CIEM/ISPM tools.

Application

MidPoint: Situation when an identity has more privileges than are necessary for the tasks that the identity is supposed to carry out.

Action taken to correct an identified identity risk or policy violation — disable orphan account, revoke excessive entitlement, fix SoD conflict, force password rotation, terminate suspicious session. May be automated (rule-triggered) or manual (admin task). Speed of remediation is key metric.

Application

MidPoint: Remediation is an action to eliminate violation of a policy, or a non-compliance with regulation or a standard.

Likelihood and impact of a security event — for identity, risks include credential theft, privilege escalation, lateral movement, insider abuse, account hijacking. Risk scoring methodologies (FAIR, NIST) quantify identity risks for prioritization. Foundation for risk-based access decisions and risk-based certification cadence.

Application

MidPoint: Effect of uncertain, unforeseen, unknown or unknowable effects on objectives.

Sources

• NIST SP 800-63 Digital Identity Guidelines (NIST) ↗ primary source

Systematic process to identify, analyze, and evaluate identity-related risks. Outputs: risk register with likelihood × impact scoring, recommended mitigations, residual risk acceptance. Required by ISO 27001 (Annex A.5/A.8), NIST CSF, GDPR Art. 32 (security of processing), DORA, NIS2.

Application

MidPoint: Risk assessment is a comprehensive process consisting of risk identification, risk analysis and risk evaluation.

Sources

• NIST SP 800-53 Rev. 5 (csrc.nist.gov) ↗ primary source

Granting insufficient access for a role — opposite of over-provisioning. Symptoms: users unable to complete tasks, frequent exception requests, shadow IT (users find workarounds outside IGA). Less common than over-provisioning but creates productivity friction and drives users to bypass governance.

Application

MidPoint: Situation when an identity has less privileges than are necessary for the tasks that the identity is supposed to carry out.

In MidPoint, Automated PD Processing refers to the platform's primary operating mode in which identity-related data and provisioning decisions are processed automatically rather than manually. In this context, it describes the normal operational flow where MidPoint evaluates synchronization, reconciliation, approval, and provisioning logic according to configured rules and tasks. The term is vendor-specific and should be understood as MidPoint's main working mode, not as a general-purpose standard term.

Client device geolocation is the determination and use of the approximate or precise physical location of a user’s endpoint device (such as a workstation, laptop, smartphone, or tablet) based on network, sensor, or positioning data. In IAM and access control, it is typically treated as a contextual attribute (e.g., IP-based location, GPS coordinates) used for risk assessment, adaptive authentication, and policy decisions. Implementations must consider accuracy limitations and regulatory constraints on collection, storage, and processing of location data.

In MidPoint, **Consent management** is the functionality for recording, tracking, and evaluating an individual's consent to process personal data. It is used to support compliance-oriented handling of consent states, including whether consent is present, valid, revoked, or otherwise applicable to a data-processing purpose. In this vendor context, it is not a separately standardized IAM term but a product capability associated with privacy and consent governance.

In MidPoint, **Cross-border PD Transfer** is the transfer of personal data to a system or recipient located in another country, typically as part of integration with foreign systems. In this product context, it refers to handling identity data flows that cross national boundaries and therefore may require additional policy, legal, or security controls. The term is used as an implementation-focused label rather than a formal standard-defined identity-management concept.

In data protection law, a **data subject (DS)** is an identified or identifiable natural person to whom personal data relate, typically defined via the notion of personal data in instruments such as the GDPR. In IAM/IGA contexts, the term is used for the individual whose identity and attributes are represented and processed in the system. In midPoint specifically, a data subject usually corresponds to a **User** object (UserType) whose personal data the system manages, though other object types (e.g. FocusType subclasses) may also hold personal data depending on configuration.

Sources

• GDPR — Regulation (EU) 2016/679 (EUR-Lex) ↗ primary source

Identity session registration is the process of recording and establishing a persistent association between an authenticated digital identity (user or non‑human identity) and a specific application or security session context. It typically involves storing session identifiers and key attributes (such as subject ID, authentication method, time, and device or client information) so that subsequent requests within that session can be reliably linked to the authenticated identity. In security architectures, identity session registration underpins access control, auditing, and risk analytics by providing a traceable record of which identity is active in which session at a given time.

An insider threat is the risk that a current or former employee, contractor, or other trusted party with legitimate access will intentionally or unintentionally misuse that access in a way that harms the organization’s confidentiality, integrity, or availability of assets. It includes malicious actions (such as data theft or sabotage) as well as negligent or compromised user behavior that leads to security incidents. In IAM/IGA practice, insider threats are mitigated through controls such as least privilege, segregation of duties, auditing, and continuous monitoring of privileged and anomalous activities.

PD anonymization in midPoint is the processing of personal data such that the resulting data set can no longer be linked to an identified or identifiable individual for the intended testing or analytics use cases. It typically involves irreversible removal or generalization of identifying attributes so that the records fall outside the scope of personal data protection obligations for those contexts. In practice, this may coexist with pseudonymized or masked copies where re-identification is still possible under stricter controls for operational needs.

In the MidPoint context, **PD Destruction** means the removal of a user from MidPoint and from connected target systems. It is an account-lifecycle action that results in the user identity and related access being eliminated in the identity-management workflow. The term is vendor-specific in this usage and should not be treated as a formal industry-standard security term.

PD dissemination in MidPoint refers to any action or process by which personal data is made available, transferred, or otherwise communicated to one or more recipients outside its original collection or primary processing context, regardless of the medium or channel. In MidPoint this is governed and constrained by policies (e.g., assignment, approval, segregation-of-duties, and privacy-related policies) that define when, to whom, and under what conditions personal data may be disseminated. Dissemination events are subject to logging, auditing, and policy enforcement to ensure compliance with applicable privacy and security requirements.

In Evolveum midPoint, **PD Provision (Personal Data Provision)** denotes the process of supplying, updating, or removing a subject’s personal data attributes from midPoint into connected target systems based on the configured provisioning policies. It typically involves mapping identity attributes to target system schemas and executing create, update, delete, or disable operations on accounts and entitlements in those systems. PD Provision events are triggered by changes in the authoritative source data, policy rules, or lifecycle state of the identity in midPoint.

Personal data (PD) is any information relating to an identified or identifiable natural person (data subject), where identifiability can be direct or indirect through reference to identifiers such as name, identification number, location data, online identifiers, or factors specific to the person’s identity.[4][5] Under GDPR and similar regimes, information about legal persons (e.g. companies) is not personal data, and truly anonymized information that cannot be linked to a living individual falls outside the scope of personal data.[3][4][5] In MidPoint, user attributes that allow direct or indirect identification of a natural person (such as names, contact details, identifiers, or HR data) must be treated as personal data and handled in accordance with applicable data protection requirements.

Personal Data Processing (PDP) is any operation or set of operations performed on personal data, such as collection, recording, storage, modification, use, disclosure, or deletion, whether automated or manual. In IAM/IGA contexts, it covers how identity systems handle personal attributes throughout their lifecycle, including synchronization, provisioning, auditing, and deletion in connected systems. In midPoint, PDP refers to the processing of personal data that occurs when the platform reads, transforms, synchronizes, and propagates user-related data between sources and targets according to defined mappings and policies.

Personally Identifiable Information (PII) is information that can be used, alone or in combination with other data, to identify a person, locate that person, or contact that person. In standards usage, PII is typically treated as a category of personal data requiring safeguards because it can reveal or enable linkage to an identifiable individual. The exact scope is jurisdiction-dependent and may vary by legal regime or industry context.

Real-time verification that identity controls remain compliant with policy and regulatory frameworks — replaces periodic point-in-time audits with continuous monitoring. Implemented via ISPM + IGA integration: configuration drift detection, real-time SoD violation alerts, MFA coverage dashboards, dormant account auto-remediation.

Application

Tools: Microsoft Defender for Identity, SailPoint Risk Manager, Saviynt ISPM, Drata, Vanta, Secureframe. Generates audit-ready evidence on demand for SOC 2, ISO 27001, HITRUST.

Process or mechanism implemented by management to provide reasonable assurance regarding effectiveness of operations, reliability of financial reporting, and compliance with laws/regulations. Identity-related internal controls: access provisioning workflows, periodic access certification, SoD enforcement, privileged access management, audit logging.

Application

SOX, SOC 2, ISO 27001, NIST 800-53 all enumerate internal control requirements. Identity controls typically classified as «IT General Controls» (ITGCs) — foundational to financial reporting reliability.

Sources

• NIST SP 800-53 Rev. 5 (csrc.nist.gov) ↗ primary source

Process to restore access when user forgets password or password is compromised — typically self-service via email/SMS verification, MFA challenge, or security questions. Major source of IT helpdesk tickets ($70+/incident per Gartner). Modern systems move toward passwordless to eliminate the problem.

Application

Best practices: passwordless preferred (FIDO2 passkeys eliminate password reset need), self-service with MFA verification (no helpdesk involvement), no security questions (low entropy, breached), no SMS for high-value accounts (SIM-swap risk).

Sources

• NIST SP 800-63 Digital Identity Guidelines (NIST) ↗ primary source

Pattern where users have the same password across multiple systems, synchronized when changed in any one. Reduces password fatigue and helpdesk burden but creates correlated compromise risk — one breach exposes all systems. Largely replaced by SSO (single authentication event) in modern enterprises.

Application

MidPoint: Outbound password mappings

Specific instance of assigning a role to an identity — captures who, when, why, with what expiration. Direct (manually requested) or derived (HR policy → role mapping). Modern best practice: derived assignments via policies for scale, direct assignments tracked as exceptions requiring justification.

Application

Audit-tracked in IGA platforms: every assignment captures requester, approver, justification, timestamp, expiration. Foundation for SOX, SOC 2, HIPAA audit evidence.

Process of defining a new role in the role catalog — naming, description, business owner, included entitlements, approval requirements for assignment. Governed: only role owners (or central role engineers) can create new roles to prevent role explosion. Role mining recommendations accelerate creation.

Application

IGA workflow: role design → entitlement bundling → business owner approval → security review → catalog publishing. Role version control captures changes over time.

Credential representing authenticated identity or authorization grant — JWT tokens, OAuth access tokens, SAML assertions, session cookies, hardware tokens. Time-limited and scope-limited. Modern best practice: short-lived tokens (minutes to hours), sender-constrained (mTLS, DPoP) to prevent token theft attacks.

Application

Standards: OAuth 2.0 access tokens, OIDC ID tokens, SAML 2.0 assertions, JWT (RFC 7519), DPoP (RFC 9449). Token theft is a primary attacker objective — defended via token binding, short lifetimes, sender constraints.

Sources

• JWT RFC 7519 ↗ primary source

Principle requiring clear, accessible information about identity processing — what data is collected, how it's used, who has access, retention periods, user rights. GDPR Articles 12-14 mandate transparency notices. Foundation of trust in CIAM systems and customer-facing identity flows.

Application

Implementations: privacy notices at identity collection points, consent receipt (proof of consent), data subject access portals showing what data is held, automated DSAR fulfillment. Tools: OneTrust, TrustArc, DataGrail.

An electronic signature is electronic data that is logically associated with other electronic data and used by a signatory to indicate approval or intention, including but not limited to cryptographic methods. In many legal and technical frameworks it serves as the electronic analogue of a handwritten signature, providing evidence of the signer’s identity and intent, and often supporting integrity and non‑repudiation depending on the implementation. The term is broader than digital signature and may encompass a range of technical mechanisms and assurance levels.

Public Key Infrastructure (PKI) — distributed system of services, components, and policies supporting cryptographic operations based on public/private key pairs. Includes Certificate Authority (CA), Registration Authority (RA), repositories (CRL/OCSP), end-entity certificates. Core standard — X.509 v3 (RFC 5280).

Sources

• RFC 5280 — X.509 Public Key Infrastructure ↗ primary source

US Department of Defense framework certifying cybersecurity practices of Defense Industrial Base (DIB) contractors handling Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). CMMC 2.0 (2021) consolidated to 3 levels: Foundational (Level 1, basic safeguarding), Advanced (Level 2, NIST SP 800-171 compliance), Expert (Level 3, NIST SP 800-172 enhanced requirements). Phased rollout in DoD contracts from 2025.

Synonyms

• CMMC 2.0

Application

Mandatory for DoD prime contractors and subcontractors handling FCI/CUI. IDM/IAM impact: MFA on all systems processing CUI, strict identity proofing (NIST SP 800-63 IAL2/AAL2 or higher), privileged access management, session monitoring for CUI access, identity federation aligned to FICAM.

Sources

• DoD CIO — CMMC Program ↗ primary source

US government program standardising security assessment and authorization of cloud services used by federal agencies. Three impact levels: Low, Moderate, High — mapping to FIPS 199 categorisation. Built on NIST SP 800-53 control baseline. Cloud Service Providers (CSPs) achieve Authority to Operate (ATO) via Joint Authorization Board (JAB) Provisional Authorization (P-ATO) or sponsoring agency authorization.

Synonyms

• FedRAMP Moderate
• FedRAMP High
• P-ATO

Application

Mandatory for CSPs serving US federal agencies. IDM/IAM impact: MFA for all privileged access (PIV/CAC tokens), audit logging per NIST SP 800-92, identity lifecycle aligned to NIST SP 800-63 (IAL/AAL/FAL levels), continuous monitoring (ConMon) of identity controls.

Sources

• FedRAMP — official portal ↗ primary source

Healthcare-focused certifiable framework consolidating HIPAA, HITECH, NIST, ISO 27001, PCI DSS, GDPR, and 40+ other authoritative sources into prescriptive controls. Three assessment levels: e1 (essential, 44 controls), i1 (implemented, 182 controls), r2 (risk-based, 197+ tailored controls). HITRUST CSF certification is the de-facto standard for healthcare vendors handling PHI.

Synonyms

• HITRUST Common Security Framework

Application

Required by major payers and providers for vendor due diligence in healthcare. IDM/IAM impact: granular role-based access to PHI, audit logging per HIPAA, automated provisioning/deprovisioning, segregation of duties for clinical vs administrative roles, session timeouts.

Sources

• HITRUST Alliance — CSF ↗ primary source

ISO/IEC 24760 — IT Security — A framework for identity management. Three-part standard defining identity management terminology (Part 1: Terminology), reference architecture (Part 2: Reference architecture and requirements), and best practices (Part 3: Practice). Authoritative source for identity vocabulary across vendor and academic publications.

Synonyms

• ISO 24760

Application

Foundation for many other identity standards (ISO 29100 privacy framework, ISO 29115 entity authentication assurance, NIST SP 800-63 alignment). Referenced in enterprise IDM RFPs as terminology baseline.

Sources

• ISO/IEC 24760-1:2019 — IT Security — A framework for identity management ↗ primary source

ISO/IEC 27000 — Information security management systems — Overview and vocabulary. Free reference document providing terminology used across the ISO 27000 family (27001 ISMS, 27002 controls, 27017 cloud, 27018 PII, 27701 privacy). Annual updates maintain alignment with evolving security domains.

Synonyms

• ISO 27000

Application

Companion to ISO 27001 certification — auditors expect terminology alignment. Modern direction: ISO/IEC 27001:2022 reorganized Annex A controls into 4 themes (organizational, people, physical, technological) with explicit identity-related controls.

Sources

• ISO/IEC 27000:2018 — ISMS overview & vocabulary ↗ primary source

NIST RBAC Standard — INCITS 359-2012 (Role-Based Access Control). Defines four RBAC variants: Flat RBAC (basic roles+users), Hierarchical RBAC (role inheritance), Constrained RBAC (SoD policies), Symmetric RBAC (review queries). De-facto international standard for RBAC implementations.

Synonyms

• NIST RBAC (INCITS 359)

Application

Foundation for most enterprise IAM RBAC implementations. Referenced in NIST SP 800-53, NIST SP 800-162 (ABAC). Modern IGA platforms (SailPoint, Saviynt, Microsoft Entra) implement Constrained RBAC + Hierarchical RBAC variants.

Sources

• NIST RBAC — INCITS 359-2012 / NIST publications ↗ primary source

AICPA auditing framework for service organizations, evaluating controls relevant to five Trust Services Criteria: Security (common criteria, required), Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 Type 1 attests to control design at a point in time; SOC 2 Type 2 attests to operating effectiveness over a period (typically 6-12 months). De-facto baseline for SaaS vendor due diligence.

Synonyms

• AICPA SOC 2
• Trust Services Criteria

Discouraged variants

• SOC1 (different scope — financial reporting controls)

Application

Required by enterprise customers before procurement of SaaS. IDM/IAM impact: documented identity lifecycle (JML), provisioning workflows, access reviews, MFA enforcement, privileged account monitoring, audit logs of all identity events. Auditors verify these via interview, sampling, and walkthroughs.

Sources

• AICPA — SOC for Service Organizations ↗ primary source

User interface label «Accept» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Add» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Apply» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Back» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Cancel» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Choose One» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Close» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Configure» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Confirm delete» rendered in MidPoint/SailPoint IIQ admin consoles.

User interface label «Create» rendered in MidPoint/SailPoint IIQ admin consoles.