Solutions
By Industry
Banking & Finance Telecommunication Public Utilities Payment Industry-agnostic
By Category
AI Data Lake & DWH Customer 360 Digital Banking Content Services Security Billing Software Smart City and Traffic Management Enterprise Resource Planning (ERP) Customer Experience
Investor
Investor relations
Investor Relations Center Dividend Policy Shareholders Analysts Financial Calendar Closed Periods IR Contact
Financial Information
Financial Highlights – consolidated Recent Results Financial Reports Presentations Financial Press Releases FAQ
Governance
Regulatory Filing Legal Environment Auditor Corporate Governance IPO
Career Center Become a Partner
About
About the Group Governance Company Structure Group Policies Norms & Certificates ESG

IAM

Identity and Access Management (IAM) is the framework of policies, processes, and technologies that ensures the right individuals and systems have appropriate access to the right resources, at the right time and for the right reasons, while preventing unauthorized access. IAM encompasses the full identity lifecycle: user provisioning and de-provisioning, authentication (verifying who you are), authorization (determining what you can access), role-based access control (RBAC), multi-factor authentication (MFA), single sign-on (SSO), privileged access management (PAM), and identity governance. IAM is a cornerstone of zero trust security architectures and a compliance requirement under regulations including GDPR, NIS2, DORA, and PSD2. Effective IAM reduces the attack surface, limits the blast radius of compromised credentials, and provides the audit trails required for regulatory reporting.

Learn more about IAM.

Single Sign-On (SSO) is an authentication framework that allows users to authenticate once with a central identity provider (IdP) and then seamlessly access multiple applications and services without re-entering their credentials for each one. SSO works by issuing a trusted authentication token or assertion, typically via SAML, OAuth 2.0, or OIDC protocols, that participating applications accept as proof of identity. For users, SSO eliminates password fatigue and reduces login friction. For IT and security teams, SSO centralizes authentication, simplifies user provisioning and de-provisioning, provides centralized audit logs, and makes it easier to enforce consistent security policies, including MFA, across all connected applications. SSO is a foundational component of enterprise IAM architectures.

Authentication and authorization are two distinct but complementary security processes that work together to control access to systems and resources. Authentication answers the question 'Who are you?', it is the process of verifying that a user, device, or system is genuinely who it claims to be, typically through credentials such as a password, biometric scan, or cryptographic certificate. Authorization answers the question 'What are you allowed to do?', it is the process of determining what resources, actions, or data the authenticated identity is permitted to access, based on assigned roles, permissions, and policies. Authentication always happens first; authorization follows. A user may be successfully authenticated (proven identity) but still be unauthorized to access specific data (insufficient permissions). Both processes are essential components of a complete IAM strategy.

A digital identity is the unique set of attributes, credentials, and data that represents an individual, organization, device, or service in a digital environment. It encompasses authentication credentials (passwords, biometric templates, cryptographic certificates), profile attributes (name, email, role, department), behavioral patterns, device associations, and access rights. In IAM, digital identity is the foundation of all access control decisions, systems grant or deny access based on the verified digital identity of the requesting entity. Robust digital identity management includes the full lifecycle of identity: creation, verification, ongoing maintenance, and eventual deactivation. Digital identity frameworks are governed by standards such as eIDAS in the EU and underpin zero trust security architectures where identity, rather than network location, is the primary trust boundary.

OAuth 2.0 is an open authorization framework (defined in RFC 6749) that enables a user to grant a third-party application limited, scoped access to their resources on a server, without sharing their credentials directly with that application. Instead of providing a username and password to a third party, the user authenticates with the resource owner (e.g., their bank or Google account) and grants the third-party app a time-limited access token that permits only the specific actions authorized. OAuth 2.0 underpins familiar flows such as 'Sign in with Google,' open banking API access under PSD2, and mobile app integrations with enterprise systems. It defines multiple grant types, including Authorization Code, Client Credentials, and Device Code, to accommodate different application types and security requirements. OAuth 2.0 handles authorization; it is typically paired with OpenID Connect (OIDC) when identity verification is also needed.

Centralizing identity and access management (IAM) across systems means establishing a single, authoritative source of identity, often called an Identity Provider (IdP), that governs authentication and authorization decisions for all applications, services, and infrastructure in your environment, rather than managing user identities and access rights separately in each system.

Here is how organizations approach IAM centralization effectively:

  1. Establish a central Identity Provider (IdP): Deploy a centralized IdP, such as an enterprise IAM platform, cloud identity service, or an on-premises directory (Active Directory, LDAP), that becomes the authoritative source for all user identities, credentials, and attributes. All applications authenticate against this single source.
  2. Implement Single Sign-On (SSO): Use federation protocols, SAML 2.0, OAuth 2.0, or OpenID Connect (OIDC), to connect all applications to the central IdP. Users authenticate once and gain access to all connected systems without re-entering credentials. This eliminates siloed, per-application identity stores that are difficult to govern and audit.
  3. Enforce Multi-Factor Authentication (MFA) centrally: Apply MFA policies at the IdP level so that strong authentication is enforced consistently across all connected applications, rather than relying on individual applications to implement their own MFA controls, which leads to inconsistency and gaps.
  4. Standardize role-based access control (RBAC): Define roles and access policies centrally and assign them to users based on their job function, department, and seniority. Access to all connected systems is then derived from these centrally managed roles, ensuring consistency and making provisioning and de-provisioning fast and reliable.
  5. Automate user lifecycle management: Integrate the IAM platform with your HR system so that user accounts are automatically provisioned when someone joins, updated when their role changes, and de-provisioned immediately when they leave, eliminating orphaned accounts, a major source of unauthorized access risk.
  6. Implement adaptive and risk-based authentication: Apply step-up authentication at the IdP level based on risk signals (device trust, geolocation, time of access, and behavior) so that higher-risk access attempts trigger stronger verification regardless of which application the user is accessing.
  7. Centralize audit logging and reporting: A centralized IAM platform aggregates all authentication and access events into a single audit log, providing the visibility needed for threat detection, incident investigation, and compliance reporting under frameworks such as GDPR, NIS2, DORA, and ISO 27001.

Centralized IAM reduces the attack surface dramatically, simplifies compliance, and gives security teams the visibility and control needed to detect and respond to identity-based threats across the entire environment.

Third-party access (granted to vendors, contractors, partners, system integrators, and managed service providers) represents one of the highest-risk categories of access in any organization. Third parties often require privileged or broad access to perform their work, they operate outside the organization's direct security controls, and they are a leading vector for supply chain attacks and data breaches. Managing third-party access securely requires a structured approach that applies the principle of least privilege, enforces strong authentication, and maintains continuous visibility.

Here are the core practices for secure third-party access management:

  1. Apply strict least-privilege access: Grant third parties only the minimum permissions necessary to perform their specific task, nothing more. Avoid sharing admin credentials or granting broad system-level access. Scope permissions to specific resources, time windows, and actions. Review and revoke access immediately when the engagement ends.
  2. Enforce MFA for all third-party accounts: Third-party accounts must be subject to the same (or stricter) authentication requirements as internal users. Multi-factor authentication (MFA) should be mandatory for all external access, with no exceptions. Phishing-resistant MFA methods such as FIDO2 or certificate-based authentication are preferred for high-privilege third-party accounts.
  3. Avoid shared or generic credentials: Each third-party user or system should have a unique, individual account. Shared credentials make it impossible to audit who did what, prevent accountability, and mean that revoking access for one individual requires changing credentials that affect others.
  4. Use time-limited and just-in-time (JIT) access: Rather than granting permanent standing access, provision third-party access only for the duration it is needed. Just-in-time access systems grant elevated permissions on request, for a defined time window, and automatically revoke them when the window closes, eliminating the persistent standing access that attackers exploit in supply chain compromises.
  5. Isolate third-party access with network segmentation: Third parties should access only the specific systems and network segments required for their work, isolated from broader corporate infrastructure. Use VPNs, zero trust network access (ZTNA), or dedicated access portals rather than granting direct network access.
  6. Monitor and record all third-party sessions: All third-party access sessions should be logged, and privileged sessions should be recorded. Session recording enables forensic investigation in the event of an incident and deters misuse. Behavioral analytics can detect anomalous third-party activity, such as accessing systems outside their scope or at unusual hours, and trigger alerts in real time.
  7. Conduct regular access reviews: Periodically review all active third-party access rights, at least quarterly for high-privilege accounts, and formally certify that access is still required and appropriate. Revoke any access that is no longer justified.
  8. Assess third-party security posture: Require third parties to meet minimum security standards, such as MFA enforcement, endpoint security, and security awareness training, as a contractual condition of access. Include right-to-audit clauses and align third-party security requirements with your obligations under GDPR, NIS2, and DORA, all of which place explicit requirements on third-party and supply chain risk management.

Secure third-party access management is not a one-time configuration. It is an ongoing governance process that requires clear policies, automated tooling, and regular review to remain effective as your third-party ecosystem evolves.