FAQ

#MFA

#Mobile App Security

#Certificate Lifecycle Management

#IAM

#3D Secure

#MFA

Multi-factor authentication (MFA) is a security process that requires users to verify their identity using two or more independent credentials before gaining access to an account, application, or system. These credentials are drawn from at least two of the following categories: something you know (a password or PIN), something you have (a smartphone or hardware token), and something you are (a fingerprint or face scan). By combining multiple factors, MFA ensures that even if one credential is compromised, for example, through a phishing attack or data breach, unauthorized access is still prevented. MFA is a foundational control in modern cybersecurity and is mandated by regulations such as PSD2, NIS2, and DORA.

Learn more about MFA.

Multi-factor authentication works by adding one or more verification steps on top of a standard username and password login. Here is how a typical MFA flow works:

The user enters their username and password (first factor: something they know).
The system prompts for a second verification step, such as a one-time password (OTP) sent via SMS, a push notification sent to a registered mobile device, or a biometric scan.
Only after both factors are successfully verified does the system grant access.

Some advanced MFA implementations use risk-based logic to skip the second step for low-risk logins (e.g., a known device on a corporate network) and only escalate to a stronger factor when unusual activity is detected. This is known as adaptive or step-up authentication.

Learn more about MFA.

Authentication factors are the independent categories of evidence used to verify indentity. There are three main factors:

Something you know - passwords, PINs, security questions
Something you have - mobile devices, hardware tokens, smart cards
Something you are - biometrics such as fingerprints and facial recognition

True MFA requires at least two factors from different categories. Using two passwords, for example, counts as a single factor authentication because both belong to the same category.

Learn more about MFA.

There are several types of multi-factor authentication, each using a different combination of verification factors:

OTP (One-Time Password): A time-limited code sent via SMS, email, or generated by an authenticator app.
Push Authentication: A push notification sent to the user's mobile device asking them to approve or deny the login.
Biometric Authentication: Verification using a fingerprint, face scan, iris pattern, or voice recognition.
Hardware Tokens: A physical device (e.g., a USB security key or smart card) that generates or stores authentication credentials.
FIDO2 / Passkeys: A phishing-resistant, passwordless standard using public-key cryptography and device-bound authenticators.
QR Code Authentication: A QR code displayed on one device is scanned by a trusted mobile device to confirm identity.
Out-of-Band (OOB) Authentication: Verification through a completely separate communication channel, such as a phone call or separate app.
Certificate-based authentication: Digital certificates that are tied to a user's identity.

The most appropriate MFA type depends on the security requirements, user experience goals, and regulatory context of the organization.

Learn more about MFA.

2FA (Two-Factor Authentication) and MFA (Multi-Factor Authentication) are closely related but not identical. 2FA is a specific subset of MFA that requires exactly two authentication factors, no more, no less. MFA is the broader category that requires two or more factors, meaning it can include three or even four verification steps for higher-security environments. In practice, most consumer-facing implementations use 2FA (e.g., password + OTP), while enterprise and high-assurance environments may deploy true multi-factor flows combining password, hardware token, and biometric verification. Both 2FA and MFA are significantly more secure than single-factor authentication (SFA), which relies on a password alone.

Lear more about M FA vs. 2FA.

Common, real-world examples of MFA include:

Passkey login on a banking app - a customer authenticates using a device-bounde passkey verified by Face ID or fingerprint, with no password involved at any point.
Transaction signing for high-value payments - a corporate banking user initiates a wire transfer and must approve it via a push notification that displays the exact amount and recipient, dynamically linking the authentication to the transaction (as required under the PSD2 SCA).
Workfoce access in a Zero Trust environment - an employee accessing a cloud-based core banking system is continuously verified based on device health, location, and behavior, with step-up MFA triggered for privileged actions.
Customer re-authentication at transaction tresholds - a retail banking customr browsing their account proceeds with minimal friction, but adding a new payee or exceeding a transation limit triggers biometric re-verification via the bank's mobile app.

Learn more about MFA.

MFA is one of the most effective security controls available because it eliminates the most common attack vector: compromised passwords. According to industry research, over 80% of data breaches involve stolen or weak credentials. MFA ensures that even if an attacker obtains a user's password through phishing, brute force, or a data breach, they still cannot access the account without the second factor, which they are unlikely to possess. Beyond preventing unauthorized access, MFA is a compliance requirement under major regulations including PSD2 (Strong Customer Authentication), NIS2, DORA, and GDPR-aligned security frameworks. For organizations, deploying MFA significantly reduces the risk of account takeover fraud, data breaches, and the financial and reputational damage that follows.

Learn more about MFA.

A one-time password (OTP) is a dynamically generated, single-use authentication code that is valid for only one login session or transaction, typically for 30 to 60 seconds. Unlike a static password, an OTP cannot be reused, making it significantly more resistant to replay attacks and credential theft. OTPs are delivered through several channels: via SMS or email (sent to a registered number or address), through an authenticator app (TOTP - Time-based One-Time Password), or displayed on a hardware token. OTPs are widely used as the second factor in MFA implementations for online banking, enterprise applications, and payment authentication.

SMS OTP is a method of delivering a one-time password to a user's registered mobile number via text message. When a user initiates authentication, the system generates a short lived numeric code and sends it to the user's phone. The user enters the code to complete verification. While SMS OTP is widely used and easy to deploy, it carries a higher risk profile than app-based or hardware OTP methods due to vulnerabilities such as SIM swapping and SS7 protocol attacks. For high-risk use cases, such as large financial transactions or privileged system access, stronger alternatives are recommended.

Biometric authentication is the process of verifying a user's identity based on unique physiological or behavioral characteristics. Common biometric modalities include fingerprint scanning, facial recognition, iris scanning, voice recognition, and behavioral patterns such as typing rhythm. Biometrics fall under the 'something you are' authentication factor and are increasingly used as a primary or second factor in MFA. They offer a strong combination of security and user convenience, users do not need to remember a password or carry a token. Biometric data is typically stored as an encrypted mathematical template (not a raw image) and compared locally on the device or against a secure server-side template during verification.

Learn more about biometric authentication.

Push authentication is an MFA method in which the authentication system sends a real-time push notification to the user's registered and trusted mobile device, prompting them to approve or deny the login or transaction with a single tap. The user does not need to manually enter a code, making it faster and more convenient than OTP-based methods while maintaining strong security. Push authentication is inherently out-of-band, the primary session occurs on one channel (e.g., a browser) while verification happens on a separate channel (the mobile device). This separation significantly reduces the risk of man-in-the-middle attacks. Push authentication is widely used in mobile banking apps and enterprise identity solutions.

Passwordless authentication is a method of verifying user identity without requiring a traditional password. Instead of a password, authentication relies on stronger and more user-friendly factors such as biometrics (fingerprint or face recognition), hardware security keys (e.g., FIDO2-compatible devices), magic links sent to a verified email address, or device-based authenticators. Passwordless authentication eliminates the most significant weakness in traditional authentication, the password itself, making it resistant to phishing, credential stuffing, and brute-force attacks. It also simplifies the user experience by removing the need to remember and manage complex passwords. Passwordless is increasingly adopted in banking, enterprise, and consumer applications as organizations look to balance security and usability.

Learn more about passwordless authentication.

Strong authentication refers to identity verification methods that go beyond a single static password and provide a significantly higher level of assurance that the user is who they claim to be. In regulatory terms, particularly under PSD2, strong authentication is defined as Strong Customer Authentication (SCA): a process that uses at least two independent factors from the categories of knowledge (password or PIN), possession (device or token), and inherence (biometrics). Strong authentication is resistant to the most common attack vectors including phishing, credential stuffing, man-in-the-middle attacks, and brute force. It is the authentication standard required for online payments in Europe and is increasingly mandated across industries.

Learn more about SCA.

Adaptive authentication is a dynamic security approach that continuously evaluates the risk of each login or transaction attempt in real time and adjusts the level of authentication required accordingly. Rather than applying the same verification step for every access event, adaptive authentication analyzes contextual signals, such as the user's device, IP address, geolocation, time of day, and behavioral patterns, to calculate a risk score. Low-risk logins (e.g., a known device, regular location, normal behavior) proceed with minimal friction. High-risk signals (e.g., a new device, unusual location, or large transaction) trigger step-up authentication, requiring the user to provide an additional factor such as biometrics or OTP. Adaptive authentication is also known as risk-based authentication (RBA) and is a core component of modern IAM and 3D Secure 2 implementations.

Risk-based authentication (RBA) is an authentication strategy that dynamically determines the appropriate level of identity verification required for each access attempt, based on a real-time assessment of the associated risk. Key risk signals evaluated include device fingerprint, IP address and geolocation, time and frequency of access, transaction amount, and deviations from established user behavior patterns. When risk is low, for example, a user logging in from their usual device and location, authentication proceeds with minimal friction. When risk is elevated, such as an unfamiliar device, unusual location, or a high-value transaction, the system escalates to a stronger authentication challenge. RBA is a foundational mechanism in fraud prevention platforms and is mandated within the 3D Secure 2 protocol for online payment authentication in Europe.

Learn more about risk-based authentication.

Step-up authentication is a security mechanism in which a user who has already authenticated at a base level, typically with a username and password, is asked to complete an additional verification step before accessing a higher-risk resource or performing a sensitive action. For example, a user logged into their banking app may be prompted for a biometric scan or OTP when initiating a large transfer or changing account settings. Step-up authentication applies the principle of proportional security: everyday actions require minimal friction, while high-stakes actions trigger stronger verification. It is a practical implementation of risk-based and adaptive authentication and is widely used in banking, healthcare, and enterprise security environments.

FIDO2 is an open authentication standard developed by the FIDO Alliance and the World Wide Web Consortium (W3C) that enables phishing-resistant, passwordless authentication using public-key cryptography. It consists of two specifications: WebAuthn (Web Authentication API), which defines how browsers and applications interact with authenticators, and CTAP (Client to Authenticator Protocol), which governs communication between the client device and an external authenticator such as a USB security key. During FIDO2 authentication, a unique cryptographic key pair is created per service, the private key stays on the user's device and never leaves it, while the public key is registered with the service. Login is verified by a cryptographic signature, meaning there are no passwords to steal, phish, or breach. FIDO2 supports device biometrics (e.g., fingerprint, Face ID), hardware tokens (e.g., YubiKey), and platform authenticators (e.g., ASEE Authenticator).

Learn more about FIDO2.

Challenge/Response (C/R) authentication is a security protocol in which the authenticating system presents the user or device with a unique challenge, typically a random value, token, or encrypted string, and the user must return the correct response derived from a shared secret or private cryptographic key. Because each challenge is unique and time-bound, C/R authentication is inherently resistant to replay attacks: intercepting a past response provides no advantage to an attacker because it will not be accepted for a different challenge. Challenge/response mechanisms underpin many authentication protocols including FIDO2, hardware OTP tokens, and cryptographic mutual authentication in secure communications.

QR code authentication is a login or transaction verification method in which a unique, time-limited QR code is displayed on one device, typically a browser on a desktop or laptop, and scanned by the user's registered and trusted mobile device to confirm their identity. The mobile device acts as a second authentication factor, combining possession (the trusted, registered device) with optional biometric verification (unlocking the phone with a fingerprint or face scan). QR code authentication is phishing-resistant because it does not involve entering credentials that could be intercepted, and it provides a seamless, low-friction user experience for cross-device scenarios such as logging into a corporate portal from a shared workstation.

The Cyber Resilience Act (CRA) is a European Union regulation that establishes mandatory cybersecurity requirements for all products with digital elements sold in the EU market, including hardware, software, and connected devices. Proposed by the European Commission in September 2022 and entering into force in December 2024, the CRA is the first EU-wide legislation to require that cybersecurity is built into digital products from the design stage, not added as an afterthought.

Under the CRA, manufacturers, importers, and distributors of products with digital elements are required to:

ensure products are designed and developed with security by default and security by design principles;
eliminate known vulnerabilities before a product is placed on the market;
provide security updates throughout the product's expected lifetime;
disclose actively exploited vulnerabilities to ENISA (the EU Agency for Cybersecurity) and national authorities - - within 24 hours of discovery;
and maintain a Software Bill of Materials (SBOM) documenting all software components.

The CRA applies to a broad range of products, from consumer IoT devices such as smart home appliances and wearables, to enterprise software, network equipment, and critical infrastructure components.

Products are classified into three risk categories:

default (most products);
important (Class I and II: products such as identity management software, firewalls, and browsers);
critical (subject to the strictest requirements).

Manufacturers of important and critical products must undergo third-party conformity assessments before affixing the CE marking required to sell in the EU. Non-compliance can result in fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. Most CRA requirements become applicable in December 2027, giving organizations a transition window to align their products and processes.

The Cyber Resilience Act (CRA) does not mandate multi-factor authneitcation (MFA) by name, but its essential cybersecurity requirement effectivelly require it in practice. The CRA obliges manufacturers and developers of products with digital elemnts sold in the EU to implement strong access control mechanisms proportional to the risk, including the prohibition of default or easily guessable credentials and the requirement to protect against unauthorized access. For any product handling sensitive data or performing security-critical functions, MFA is the standard mechanism that satisfies these obligations. Organizations seeking CRA compliance should therefore treat MFA as a baseline security control, not an optional enhancement.

top

#Mobile App Security

Mobile applications have become a primary interface for banking, payments, healthcare, and enterprise productivity, making them a high-value target for cybercriminals. Unlike traditional software deployed in controlled server environments, mobile apps run on devices outside the organization's security perimeter, in environments that may be rooted, jailbroken, or infected with malware. Without adequate mobile app security controls, attackers can reverse-engineer app logic, steal credentials and cryptographic keys, inject malicious code, perform overlay attacks to capture user input, and distribute tampered clones of legitimate apps. A strong mobile app security strategy protects both the application and its users, preserves regulatory compliance (e.g., PSD2, GDPR, DORA), and safeguards the organization's brand and customer trust.

Learn more about the importance of mobile app security.

The most common mobile app vulnerabilities, as documented by the OWASP Mobile Top 10, include:

Insecure Data Storage: Sensitive data stored in plaintext on the device, accessible to malicious apps or physical attackers.
Insufficient Cryptography: Use of weak, outdated, or incorrectly implemented encryption algorithms.
Insecure Communication: Failure to enforce TLS or improper certificate validation, enabling man-in-the-middle attacks.
Insecure Authentication: Weak or missing authentication controls allowing unauthorized access.
Improper Platform Usage: Misuse of platform APIs, permissions, or features such as clipboard access or background location.
Code Tampering: Modification of the app binary to bypass security controls or inject malicious functionality.
Reverse Engineering: Lack of obfuscation enabling attackers to analyze app logic, extract secrets, or clone the app.
Extraneous Functionality: Debug code or hidden backdoors left in production releases.

Addressing these vulnerabilities requires a layered mobile security approach combining secure coding practices, code obfuscation, RASP, and runtime integrity monitoring.

Learn more about mobile app vulnerabilities.

Reverse engineering in mobile app security is the process of deconstructing a compiled app binary to understand its internal logic, architecture, algorithms, and embedded data , without access to the original source code. Attackers use reverse engineering tools (such as jadx, apktool, Frida, or Ghidra) to analyze how an app works, discover hardcoded API keys and cryptographic secrets, identify exploitable logic flaws, and create unauthorized clones or modified versions of the app. Reverse engineering is a prerequisite for many other mobile attacks, including tampering, credential theft, and overlay fraud. The primary defenses are code obfuscation (making the code unreadable after decompilation) and binary protection techniques that prevent static analysis tools from fully reconstructing the app logic.

Watch webinar on understanding and preventing reverse engineering.

App tampering is the unauthorized modification of a mobile application's binary code, resources, configuration files, or runtime behavior. Attackers tamper with apps to bypass license checks or paywalls, remove security controls such as certificate pinning or root detection, inject malicious code to steal credentials or intercept communications, or repackage and redistribute the app as a trojanized fake. Tampered apps pose a significant threat to users who unknowingly install compromised versions, and to organizations whose brand and security posture is undermined. Anti-tampering controls, including cryptographic code signing, runtime integrity verification, and RASP, detect and respond to tampering attempts in real time.

Code obfuscation is a mobile and software security technique that transforms an application's source code or compiled binary into a functionally identical but extremely difficult-to-understand form. Obfuscation does not change what the code does, it only makes it much harder for attackers using reverse engineering tools to understand how it does it. Common obfuscation techniques include renaming classes, methods, and variables to meaningless identifiers; encrypting strings; inserting dummy code and dead branches to confuse analysis; and applying control flow obfuscation to scramble the execution path. Code obfuscation is a critical first layer of mobile app protection, making it significantly harder to extract business logic, API keys, cryptographic secrets, or authentication mechanisms from the app.

RASP (Runtime Application Self-Protection) is a security technology built directly into a mobile or web application that protects it from attacks while it is running, from the inside out. Unlike firewalls or network-based security that protect the perimeter around an application, RASP sits inside the app itself and monitors its behavior in real time. If RASP detects a threat, such as an attacker trying to hook into the app's functions, run it in an emulator, attach a debugger, or tamper with its code, it can block the attack, terminate the session, or alert the security team, all without any human intervention. Think of RASP as a built-in bodyguard that travels with the app wherever it runs, providing protection even in hostile or uncontrolled environments.

Learn more about RASP.

Mobile app shielding is a comprehensive set of security protections applied to a mobile application to make it resilient against attacks, even when deployed on compromised, rooted, or jailbroken devices. It combines multiple layers of defense into a unified security wrapper built directly into the app, typically including: code obfuscation to prevent reverse engineering, RASP (Runtime Application Self-Protection) for real-time threat detection and response, anti-debugging and anti-tampering controls, root and jailbreak detection, emulator detection, and runtime integrity verification. App shielding is particularly important for applications operating in uncontrolled end-user environments, such as mobile banking apps, payment apps, and digital identity solutions, where the organization cannot control the security state of the device.

Learn more about mobile app shielding.

Mobile app hardening is the process of applying a comprehensive set of security controls to a mobile or web application to significantly increase its resistance to attacks, particularly when deployed in untrusted, hostile, or uncontrolled environments. For mobile apps, hardening encompasses a multi-layered approach including: code obfuscation and binary protection to prevent reverse engineering; RASP for runtime threat detection and response; anti-debugging and anti-tampering controls; secure storage enforcement to prevent sensitive data from being stored in accessible locations; certificate pinning to prevent man-in-the-middle attacks; and root/jailbreak detection to identify compromised device environments. A hardened application maintains its security posture and continues to protect sensitive operations even when running on a compromised device.

Learn more about mobile app hardening.

Mobile malware is malicious software specifically designed to infect smartphones and tablets, enabling attackers to steal sensitive data, spy on users, intercept communications, or gain unauthorized control of the device. Common types of mobile malware include:

Banking Trojans: Overlay the screens of legitimate banking apps to steal credentials and OTPs.
Spyware: Silently monitors and transmits user activity, keystrokes, and communications to a remote attacker.
Ransomware: Encrypts device data or locks the screen, demanding a ransom for restoration.
Adware: Generates revenue for attackers through unwanted advertising while consuming device resources.
RATs (Remote Access Trojans): Give attackers full remote control over the infected device.

Mobile malware is typically distributed through malicious app stores, phishing links, trojanized apps, and drive-by downloads. Mobile app security controls such as RASP, integrity checking, and overlay detection are key defenses.

A rooted device (Android) or jailbroken device (iOS) is a smartphone or tablet on which the manufacturer's software restrictions have been removed, granting the user, and any software running on the device, unrestricted, root-level access to the operating system. While rooting and jailbreaking can enable greater device customization, they also disable key platform security features including app sandboxing, verified boot, and system integrity protections. From a security perspective, rooted and jailbroken devices are significantly more vulnerable: they can run unauthorized apps from untrusted sources, allow malware to operate with elevated privileges, and enable attackers to hook into or tamper with legitimate applications. Security-sensitive apps, such as banking, payment, and authentication apps, implement root and jailbreak detection to refuse operation or warn users when a compromised device environment is detected.

Learn more about the risks of jailbreaking.

Mobile app integrity refers to the guarantee that a mobile application has not been altered, tampered with, or repackaged since it was originally built, signed, and published by its developer. App integrity verification works by validating cryptographic signatures and checksums of the app's components at runtime, ensuring that every part of the app, its code, resources, and configuration, matches the original authorized version. If any modification is detected, the app can refuse to run, terminate the session, or alert the security team. App integrity is critical for preventing the distribution and use of trojanized app clones, which are a common vector for credential theft, fraud, and data exfiltration in mobile banking and payment environments.

Learn more about mobile app integrity check.

The OWASP Mobile Top 10 is a regularly updated list published by the Open Worldwide Application Security Project (OWASP) that identifies the ten most critical security risks affecting mobile applications. It serves as an authoritative reference for mobile app developers, security teams, and auditors, providing guidance on identifying, understanding, and mitigating the most prevalent mobile vulnerabilities. The current OWASP Mobile Top 10 includes risks such as improper credential usage, inadequate supply chain security, insecure authentication and authorization, insufficient input/output validation, insecure communication, inadequate privacy controls, insufficient binary protections, security misconfiguration, insecure data storage, and insufficient cryptography. Aligning mobile app security practices with the OWASP Mobile Top 10 is considered an industry best practice and is referenced in many regulatory security frameworks.

Learn more about OWASP top 10 vulnerabilites for mobile.

Mobile threat detection is the real-time identification and analysis of security threats targeting mobile applications and the devices they run on. It encompasses a broad range of detection capabilities including: identifying rooted or jailbroken devices that pose elevated risk; detecting the presence of malware, spyware, or unauthorized apps on the device; recognizing hooking frameworks and debugger attachment attempts; detecting emulator or virtual device environments commonly used for automated fraud; monitoring for overlay attacks that attempt to capture user input; and identifying tampering with the app binary or its runtime environment. Mobile threat detection is implemented through RASP, mobile security SDKs, and mobile threat defense (MTD) platforms, providing the visibility needed to respond to threats in real time without requiring server-side intervention.

An overlay attack is a technique in which malicious software displays a fake, transparent screen on top of a legitimate app, such as a banking or payment application, to capture credentials, OTPs, or card details as the user types them. The victim interacts with what appears to be the genuine app, unaware their input is being intercepted. Overlay attacks are among the most common techniques used by banking trojans on Android. Defenses include RASP-based overlay detection and runtime integrity monitoring.

A hooking attack intercepts function calls within a running mobile application, allowing an attacker to monitor, modify, or redirect app behavior without altering the app binary. Using frameworks such as Frida or Xposed, attackers hook into sensitive functions, such as authentication checks, encryption routines, or API calls, to extract credentials, bypass security controls, or manipulate transaction data. Hooking attacks require the app to be running and are typically performed on rooted or jailbroken devices. RASP detects and blocks hooking attempts at runtime.

Learn more about the risks of mobile app hookign.

Mobile emulators simulate real device environments on desktop computers, allowing fraudsters to impersonate thousands of different devices from a single machine. In fraud attacks, emulators are used to automate credential stuffing, account takeover attempts, and fake account creation at scale, bypassing device-based fraud signals that rely on real hardware fingerprints. Emulator-based fraud is particularly prevalent in mobile banking and payments. Detection involves identifying emulator artifacts (inconsistent hardware signatures, missing sensors, abnormal system properties) at the application layer.

Learn more about mobile emulators fraud.

Dynamic instrumentation is the process of injecting code into a running application to observe or modify its behavior in real time, without recompiling it. Tools such as Frida enable attackers to hook into app functions, dump memory, bypass certificate pinning, extract cryptographic keys, and disable security controls, all while the app is executing. It is one of the most powerful techniques available to mobile app attackers and is difficult to detect with static analysis alone. RASP and anti-hooking controls are the primary defenses.

Tamper detection works by validating the app's cryptographic signature and checksums at runtime, confirming that the binary, resources, and configuration files match the original signed version published by the developer. If any component has been modified (for example, to remove license checks, inject malicious code, or bypass authentication) the integrity check fails and the app can refuse to run or terminate the session. Tamper detection is typically implemented as part of a RASP or app shielding solution and operates continuously throughout the app's lifecycle, not just at startup.

RASP (Runtime Application Self-Protection) is embedded directly into the app and continuously monitors its execution environment. When a threat is detected (such as a debugger being attached, a hooking framework being active, the app running in an emulator, the device being rooted or jailbroken, or the app binary having been tampered with) RASP can respond immediately by blocking the specific operation, terminating the session, or alerting the security team. Because RASP operates from inside the app, it provides protection regardless of the network environment or device security state, unlike perimeter controls that can be bypassed.

Learn more about RASP.

A mobile WAF (Web Application Firewall) operates at the network layer, inspecting HTTP/S traffic between the app and the server to block malicious requests. It protects the server-side API but has no visibility into what is happening inside the app itself. RASP operates inside the app at the application layer, protecting the client-side runtime from threats such as hooking, tampering, emulator use, and reverse engineering - threats a WAF cannot see. The two are complementary: a WAF secures the backend, RASP secures the app.

Certificate pinning is a technique that hardcodes the expected TLS certificate or public key directly into the mobile app, so the app only accepts connections from a server presenting that specific certificate, regardless of what the device's certificate store trusts. This prevents man-in-the-middle attacks where an attacker intercepts encrypted traffic by presenting a fraudulent but CA-signed certificate. Without pinning, an attacker who can install a trusted certificate on the device can decrypt all app traffic. Certificate pinning is particularly important for banking and payment apps where API traffic contains sensitive financial data.

The terms are closely related and often used interchangeably, but there is a meaningful distinction. App hardening refers to the broader process of applying security controls to reduce an application's attack surface, including secure coding practices, removal of debug code, secure storage configuration, and minimizing permissions. App shielding is a specific subset of hardening focused on protecting the app binary and runtime from external attack through code obfuscation, RASP, anti-tampering, and anti-debugging controls. In practice, a fully hardened app incorporates shielding as one of its layers, alongside other secure development lifecycle (SDLC) controls.

Banking and financial mobile apps are subject to several overlapping security standards and regulatory requirements.

PSD2 requires Strong Customer Authentication (SCA) and dynamic linking for payment transactions in Europe.

The OWASP Mobile Application Security Verification Standard (MASVS) defines security requirements across architecture, data storage, cryptography, authentication, nework communication and resilience.

DORA requires financial entities to manage ICT risks, including mobile app security, as a part of their digital operational resilience framework.

PCI DSS applies to any app that processes, stores, or transmits payment card data.

National financial regulators (such as EBA guidelines) may impose additional requirements specific to mobile banking.

Yes. PSD2 directly impacts mobile app security in two ways. First, it mandates Strong Customer Authentication (SCA) for payment initiation and account access, requiring mobile apps to implement MFA using at least two independent factors. Second, it requires dynamic linking. Each transaction must be bound to a specific amount and payee via a unique authentication code, preventing transaction manipulation attacks such as man-in-the-browser.

Beyond authentication, PSD2's broader security obligations, combined with EBA guidelines on operational and security risk, require payment service providers to implement measures that protect the integrity and confidentiality of users' personalized security credentials, which extends to the mobile app environment.

NIS2 does not regulate mobile applications directly, but it applies to the organizations that develop and operate them if those organizations fall within its scope. This includes entities in sectors such as banking, financial market infrastructure, digital infrastructure, and managed service providers. For in-scope organizations, NIS2 requires appropriate and proportionate technical security measures across their ICT environment, including the applications they develop and operate. This encompasses mobile apps that form part of the organization's service delivery, particularly those handling sensitive data or performing critical functions. NIS2 also requires supply chain security measures, which extend to third-party mobile SDKs and libraries.

Learn more about NIS2.

An unprotected mobile app can be reverse-engineered within hours using freely available tools, exposing business logic, API keys, cryptographic secrets, and authentication mechanisms. Attackers can use this knowledge to create counterfeit clones distributed through unofficial app stores, conduct targeted API attacks using extracted credentials, and bypass security controls entirely. For end users, unprotected apps are vulnerable to overlay attacks, credential theft, and session hijacking. For the organization, the consequences include financial fraud, data breaches, regulatory penalties under GDPR and PSD2, and lasting reputational damage. These are particularly severe in financial services where customer trust is a core business asset.

The key evaluation criteria are:

depth of protection (does it cover obfuscation, RASP, anti-tampering, root/jailbreak detection, emulator detection, and certificate pinning in a single solution?);
integration simplicity (SDK-based solutions that integrate without requiring source code changes reduce deployment friction significantly);
performance impact (security controls must not materially degrade app performance or battery life);
coverage across platforms (iOS and Android);
configurability of threat responses (block, warn, or log depending on the threat severity);
vendor expertise in your sector.

For regulated industries, verify that the solution supports compliance with PSD2, DORA, and OWASP MASVS requirements.

The direct costs of a mobile app security breach include fraud losses (unauthorized transactions, account takeovers), incident response and forensic investigation, mandatory breach notification under GDPR (which requires notification within 72 hours and can trigger fines of up to 4% of global turnover), regulatory penalties, and legal liability. Indirect costs, often larger, include customer churn, reputational damage, loss of competitive advantage if proprietary business logic is stolen, and the engineering cost of emergency patching and re-releasing the app. For financial services organizations, a breach affecting mobile banking infrastructure can also trigger regulatory scrutiny of the entire security program under NIS2 and DORA, amplifying the long-term operational cost well beyond the immediate incident.

top

#Certificate Lifecycle Management

TLS/SSL certificates are digital certificates issued by a trusted Certificate Authority (CA) that serve two critical functions: they authenticate the identity of a server (proving that a website or service is genuinely who it claims to be) and they enable encrypted communication between the server and the client using the TLS (Transport Layer Security) protocol. When a browser connects to a website secured with a TLS certificate, it verifies the certificate's authenticity against the CA's trusted root, establishes an encrypted session, and displays the padlock icon and HTTPS prefix in the address bar. TLS certificates contain key information including the domain name they protect, the issuing CA, the certificate's validity period, and the server's public key. Despite being technically TLS certificates, they are still commonly referred to as SSL certificates, a legacy term from the now-deprecated Secure Sockets Layer protocol.

TLS/SSL certificates are fundamental to internet security for three core reasons. First, they encrypt all data transmitted between a user's browser and the server, protecting sensitive information, including credentials, payment card data, and personal details, from interception by third parties. Second, they authenticate the server's identity, ensuring users are communicating with the genuine website and not a fraudulent impersonator (a defense against phishing and man-in-the-middle attacks). Third, they are a baseline trust signal: browsers actively warn users when a site lacks a valid TLS certificate, and search engines such as Google use HTTPS as a ranking factor. For organizations, maintaining valid, properly configured TLS certificates is a compliance requirement under frameworks such as PCI DSS, GDPR, NIS2, and DORA, and a prerequisite for customer trust in any digital service.

When a user connects to an HTTPS website, a process called the TLS handshake takes place. During this handshake, the server presents its TLS certificate, the client verifies it agains a trusted Certificate Authority (CA), and both parties negotiate encryption parameters. This process relies on asymmetric encryption, using a public key and a private key, to securely exchange a session key, after which symmetric encryption takes over for the remainder of the session for performance efficiency. Algorithms such as RSA, ECC (Eliptic Curve Cryptography), and AES (Advanced Encryption Standard) are commonly used in this process.

TLS/SSL certificates differ in the level of identity verificiation performad by the Certificate Authority (CA) before issuance, making some types more appropriate for ceratin use cases than others.

Domain Validation (DV) certificates offer the most basic level of verification. The CA confirms only that the applicant controls the domain in question, no organizational identity is checked. Because the validation process is fully automated, DV certificates are issued within minutes. They are well suited for blogs, infomational webistes, and for internal toools where basic encrypted connection is sufficient, but they provide no assurance about the organization behind the website.

Certificate expiration occurs when a TLS/SSL digital certificate reaches the end of its predefined validity period. This is typically 1 year (398 days for publicly trusted certificates, as mandated by CA/Browser Forum baseline requirements). Once a certificate expires, browsers and clients no longer trust it, immediately triggering visible security warnings ( " Your connection is not private " ) that block users from accessing the service. Expired certificates cause service outages, damage customer trust, and can constitute a compliance violation. Certificate expiration is one of the most common and preventable causes of website downtime, making proactive expiration monitoring and automated renewal essential practices for any organization managing digital certificates.

Certificate renewal is the process of replacing an expiring or expired TLS/SSL certificate with a newly issued certificate from a Certificate Authority (CA) before the existing one becomes invalid. Renewal maintains the continuity of trusted encrypted communications and prevents the service outages and browser security warnings associated with expired certificates. Certificate renewal can be performed manually, by generating a new certificate signing request (CSR), submitting it to the CA, and deploying the new certificate, or automatically using protocols such as ACME (Automatic Certificate Management Environment), which enables zero-touch renewal without human intervention. Automated renewal is strongly recommended for organizations managing large numbers of certificates, as manual processes are error-prone and difficult to scale.

Certificate management is the systematic set of processes and tools used to discover, track, issue, deploy, monitor, renew, and revoke digital certificates across an organization's entire IT infrastructure. As organizations scale, deploying certificates across web servers, APIs, microservices, IoT devices, and internal systems, the volume and complexity of certificate management grows rapidly. Without a centralized certificate management platform, organizations face significant risks: missed expirations causing outages, shadow certificates issued outside of IT's visibility, and compliance gaps. Effective certificate management provides a complete inventory of all certificates, automated lifecycle workflows, expiration alerting, and audit trails to support compliance with regulatory requirements such as PCI DSS, NIS2, and DORA.

The certificate lifecycle is the complete sequence of stages that a digital certificate passes through from creation to retirement. The key stages are:

Request - an entity generates a key pair and submits a Certificate Signing Request (CSR) to a Certificate Authority.
Issuance - the CA validates the request and issues the signed certificate.
Deployment - the certificate is installed and activated on the target server, device, or service.
Monitoring - the certificate is tracked for validity, configuration correctness, and approaching expiration.
Renewal - the certificate is renewed before it expires, maintaining continuity of service.
Revocation - if the certificate is compromised or no longer needed, it is revoked and added to the CA's Certificate Revocation List (CRL) or OCSP records.
Retirement - the expired or revoked certificate is decommissioned and removed from inventory. Managing the full certificate lifecycle, particularly at scale, requires automated tooling to prevent the operational and security risks associated with unmanaged certificates.

A wildcard certificate is a TLS/SSL certificate that secures a primary domain and all of its first-level subdomains under a single certificate, identified by an asterisk in the subject field (e.g., *.example.com). A single wildcard certificate for *.example.com will secure app.example.com, api.example.com, portal.example.com, and any other subdomain at that level, without needing separate certificates for each. This significantly simplifies certificate management for organizations with multiple subdomains. However, wildcard certificates carry a broader risk profile than single-domain certificates: if the private key associated with a wildcard certificate is compromised, all subdomains it covers are potentially exposed. Wildcard certificates do not cover second-level subdomains (e.g., dev.app.example.com) and are not suitable for all use cases.

A self-signed certificate is a TLS/SSL certificate that is signed by the same entity that created it, the certificate holder, rather than by a trusted, third-party Certificate Authority (CA). Because self-signed certificates are not issued by a recognized CA, browsers and operating systems do not trust them by default and display prominent security warnings when they are encountered. Self-signed certificates are appropriate for internal development environments, testing, internal-only services where the certificate can be manually distributed and trusted, and certain machine-to-machine communications where mutual trust is established out of band. They should never be used for public-facing websites, APIs, or any service where end-user trust and regulatory compliance are required, as the absence of third-party validation provides no assurance of the server's identity.

When a TLS/SSL certificate expires, the trust chain that browsers and clients rely on to verify a server's identity immediately breaks. The consequences are immediate and cascading:

Browser security warnings: Users are shown a prominent "Your connection is not private" or "Certificate expired" error page. Most users will not proceed past this warning, effectively taking the service offline from their perspective.
Service outages: APIs, mobile apps, IoT devices, and internal systems that perform certificate validation will refuse to connect, causing application failures and integration breakdowns across dependent services.
Loss of encryption: Without a valid certificate, encrypted HTTPS communication cannot be established, leaving data in transit unprotected.
Compliance violations: Expired certificates constitute a failure of security controls required under regulations such as PCI DSS, GDPR, NIS2, and DORA, potentially triggering audit findings and regulatory penalties.
Reputational damage: Visible security errors erode customer trust rapidly and can result in lasting brand damage, particularly for financial services and healthcare organizations.

The most effective prevention is automated certificate lifecycle management. Tools that continuously monitor certificate expiration dates, alert well in advance of expiry, and trigger automatic renewal via protocols such as ACME, eliminating the risk of human oversight causing a missed renewal.

The ACME (Automatic Certificate Management Environment) protocol is an open standar, defined in RFC 8555, that automates the issuance, renewal, and revocation of TLS/SSL certificates between a web server or client and a Certificate Authority (CA). ACME is the protocol that powers Let's Encrypt and is supported by a growing number of public and private CAs, making it the foundation of zero-touch certificate lifecycle management.

Here is how the ACME protocol works step by step:

Account creation: The ACME client (running on the server) registers an account with the CA by generating a key pair and submitting the public key.
Order submission: The client submits a certificate order specifying the domain name(s) to be covered.
Domain validation (challenge): The CA issues a challenge to prove the client controls the domain. The two most common challenge types are HTTP-01 (the client places a specific token at a known URL on the domain) and DNS-01 (the client creates a specific DNS TXT record). Wildcard certificates require DNS-01 validation.
Challenge verification: The CA verifies the challenge response. Once validated, the domain authorization is stored.
Certificate issuance: The client submits a Certificate Signing Request (CSR), and the CA issues and returns the signed certificate.
Automated renewal: The ACME client is configured to repeat this process automatically, typically 30 days before expiration, requiring zero human intervention.

ACME eliminates the manual steps that make certificate management error-prone at scale, and is the recommended approach for any organization seeking to implement automated, zero-touch certificate renewal.

Certificate sprawl is the uncontrolled proliferation of TLS/SSL certificates across an organization's IT infrastructure resulting from inconsistent issuance practices, lack of centralized visibility, decentralized ownership, and reliance on manual processes. In large enterprises, certificates are issued across cloud environments, on-premises servers, microservices, APIs, IoT devices, and internal applications. This is often done by different teams using different CAs, with no single system tracking them all.

Certificate sprawl creates several serious risks:

Invisible expirations: Certificates that are not tracked are not renewed, leading to unexpected outages when they expire silently.
Shadow certificates: Certificates issued outside of IT governance (by developers, third-party vendors, or automated tooling) are unknown to the security team, creating unmanaged attack surfaces.
Inconsistent security standards: Sprawled certificates may use outdated algorithms, weak key lengths, or inappropriate validity periods that do not meet current security standards.
Compliance gaps: Regulators and auditors require organizations to demonstrate control over all certificates in use — an impossible task without a centralized inventory.
Incident response delays: When a CA is compromised or a certificate must be urgently revoked, certificate sprawl makes it extremely difficult to identify all affected certificates quickly.

The solution to certificate sprawl is a centralized certificate management platform that provides automated discovery of all certificates across the environment, a unified inventory, lifecycle automation, and policy enforcement, regardless of which CA issued the certificate.

Multi-tenant TLS certificate management is the capability of a certificate management platform to manage digital certificates across multiple distinct organizational units, clients, business divisions, or customer environments — each with their own isolated policies, CA configurations, certificate inventories, and access controls — from a single, centralized platform instance.

This model is essential in several contexts:

Managed Security Service Providers (MSSPs) and managed PKI providers that manage certificates on behalf of multiple enterprise clients, each requiring strict data isolation and separate reporting.
Large enterprises with multiple subsidiaries, business units, or geographic regions that operate semi-independently but require centralized governance and visibility.
Cloud service providers and SaaS platforms that issue and manage TLS certificates for customer-facing endpoints across a large customer base.

Key capabilities of a multi-tenant certificate management solution include:

tenant-level isolation of certificate inventories, CA connections, and policies;
role-based access control scoped to individual tenants;
consolidated reporting and dashboards for administrators with cross-tenant visibility;
separate billing and quota management per tenant;
support for both shared and tenant-specific CA integrations.

Multi-tenant certificate management significantly reduces operational overhead while maintaining the governance, security, and compliance standards required by each individual tenant.

Zero-touch TLS certificate renewal is the fully automated process of renewing digital certificates before they expire without requiring any manual action from IT or security teams. In a zero-touch renewal model, the certificate management system or ACME client continuously monitors certificate expiration dates, automatically initiates the renewal process a configurable number of days before expiry, completes domain validation, obtains the new certificate from the CA, and deploys it to the target server or service, all without human intervention.

Zero-touch renewal is made possible by the ACME protocol (RFC 8555), which standardizes automated communication between certificate clients and Certificate Authorities. When combined with a certificate management platform, zero-touch renewal can extend across complex, hybrid environments covering cloud infrastructure, on-premises servers, load balancers, CDNs, and internal services.

The business case for zero-touch renewal: Certificate expiration is one of the most common and entirely preventable causes of service outages and security incidents. As organizations manage growing numbers of short-lived certificates (the CA/Browser Forum is progressively reducing maximum certificate validity periods, with 47-day certificates expected by 2027), manual renewal processes become operationally unsustainable. Zero-touch renewal eliminates expiration risk at scale, reduces operational overhead, and supports compliance with the continuous security monitoring requirements of frameworks such as NIS2, DORA, and PCI DSS.

Yes, for most enterprises, support for both public and private Certificate Authorities (CAs) is a fundamental requirement of any effective TLS certificate management platform.

Public CAs (such as DigiCert, Sectigo, Let's Encrypt, and GlobalSign) issue certificates that are trusted by default in browsers and operating systems worldwide. They are used for public-facing websites, customer-facing APIs, and any service that must be trusted by external users without additional configuration.

Private CAs (also called internal or enterprise CAs, such as Microsoft Active Directory Certificate Services or a self-hosted PKI) issue certificates that are trusted only within an organization's controlled environment. They are used for internal services, microservices communication, machine-to-machine (M2M) authentication, VPN gateways, internal APIs, IoT device identity, and DevOps infrastructure — environments where purchasing public CA certificates at scale would be impractical and where the organization maintains its own trust anchor.

A certificate management platform that supports only public CAs will leave a significant portion of the certificate estate unmanaged. This creates the exact visibility and governance gaps that lead to certificate sprawl, surprise expirations, and compliance failures. Also, a platform that only supports private CAs cannot manage the public-facing certificate estate. Enterprises typically operate both types simultaneously, and the management platform must provide a unified inventory, automated lifecycle workflows, and consistent policy enforcement across all CAs, public and private, from a single tool. Support for the ACME protocol, SCEP, EST, and CA-specific APIs ensures compatibility across the broadest range of CA providers.

top

#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:

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.
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.
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.
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.
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.
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.
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:

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.
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.
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.
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.
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.
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.
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.
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.

top

#3D Secure

eCommerce popularity has increased constantly over the last ten years. 3D Secure is a protocol designed for increased security during online payments using credit and debit cards (Card-Not-Present transactions). The main purpose of 3D Secure is to authenticate the cardholder during online payment on the internet or mobile purchasing. To make a parallel with in-store payment, the cardholder is authenticated either with signature or PIN, which are not applicable during online payment.

The concept of 3D Secure is based on the 'Three-Domain' model, including all participants involved in the financial transaction. All three domains participate in the authentication process, and compliance in all three domains results in a 100% secure transaction. Non-compliance under any of the domains moves the liability shift towards the weaker party. The three domains are: Acquirer domain (where 3D Secure transactions are initiated), Interoperability domain (where transactions are switched between Acquirer and Issuer domains), and Issuer domain (where transactions are authenticated).

For Issuers, the most relevant component is the Access Control Server (ACS). Additionally, depending on the chosen authentication method, the Issuer should have an authentication solution integrated with ACS, and the solution needs to be certified by card schemes. For Acquirers, the most relevant component is the Merchant Plug-In (MPI). In 3D Secure 2.0, instead of MPI, a 3DS Server is introduced, along with SDK components for mobile purchase applications.

3D Secure 2 specifications by EMVCo, as well as card scheme 3D Secure 2 programs (MC Identity Check, Verified By Visa, etc.), are aligned with PSD2 requirements. When deploying 3D Secure 2, Issuers/Acquirers are aligned with PSD2 for Card-Not-Present online payments. Note that it covers only Card-Not-Present online payments, not account-to-account payments and other PSD2 relevant scopes.

Instead of purchasing ACS products to be implemented on bank premises, Issuing banks can use third-party service providers to outsource the 3D Secure process. Card schemes certify and approve service providers who can provide this service to the Issuing bank. ASEE has been certified as a MasterCard and VerifiedByVisa ACS service provider. By using this service, Issuing institutions minimize time to market, reduce investment and operational costs, and provide their customers with ultimate fraud protection during online payment.

3D Secure 2.0 contains two authentication flows: Frictionless flow and Challenge flow. Frictionless flow enables cardholders to process online payments without demanding any manual input in order to authenticate the transaction. This is possible because of Risk-Based Authentication, a mechanism that assesses the risk level of a particular transaction based on historical data, including transaction history and provided cardholder information. If a transaction is deemed low risk, frictionless flow is applied, eliminating the need for additional authentication steps from the cardholder.

3D Secure 2.0 contains two authentication flows: Frictionless flow and Challenge flow. Challenge flow is applied in cases where the Issuer's ACS deems a transaction as risky. In such cases, the cardholders are required to verify their identity using an appropriate authentication method (e.g., OTP, fingerprint, face recognition).

Trides ACS enables Issuers to provide 3D Secure processing with MasterCard, VISA, Amex, JCB, and Mir cards with two-factor strong authentication in compliance with 3D Secure v1.0.2 and the new 3D Secure v2.1 protocol. Trides MPI v1.0.2 and Trides 3DS Server v2.1.0 with Android and iOS SDK enable Acquirers and Merchants to integrate web and mobile purchase applications with multiple interoperability domains and initiate online payments within 3D Secure scheme. ASEE also offers 3DS Mobile SDK implementation.

With 3D Secure mobile SDK, the merchants are able to build in all 3D Secure screens into their mobile purchase application to provide a faster and smoother checkout experience. Without it, the cardholders need to switch to the web browser during 3D Secure authentication, which disturbs the checkout process.

If you have any additional questions regarding 3D Secure solutions or hosting services, need advice or support related to 3D Secure online fraud protection for your customers, contact your ASEE Key Account Manager, Sales Representative or send an email at trides@asseco-see.hr.

Deadlines vary depending on the card scheme. VISA announced a deadline for card issuers and merchants to migrate to 3DS v2.0 of October 2022, worldwide. MasterCard shared its expected deadline of October 2022.

MasterCard and Visa plan the shutting down of 3DS 1.0 in October 2022. After that, the service won't be available; hence all participants should switch to 3DS 2.0.

This is a transition period, and Issuers are able to time their implementation. However, since regulations are defined, all market participants will pursue implementation of 3D Secure solutions, narrowing down the window for fraudulent transactions. Non-ACS Issuers will be even more vulnerable to fraud during the transition period, as they will be targeted by criminals due to lack of security. In short, the sooner the implementation, the lower the risk.

Issuers who have 3D Secure 1.0.2 deployed should apply the following guidelines from EMVCo: (1) Abandon user activation or activation during shopping by activating all cards enrolled in the 3D Secure scheme. (2) Deploy two-factor strong authentication methods instead of static passwords. (3) Deploy simplified risk assessment and Risk-Based authentication to process low-risk transactions without cardholder authentication.

When banks implement 3D Secure 2, if they already supported 3D Secure 1.0.2, they should continue to support 3D Secure 1.0.2 until October 2022. That means that in this period, two schemes will coexist. MasterCard requires running both versions in the transition period.

The most convenient method to migrate from 3D Secure 1.0.2 to 3D Secure 2.0/2.1 is by outsourcing 3D Secure infrastructure and service. Issuers who use ACS hosting services do not have any technical impacts when upgrading to the latest version/platform. There is only paperwork related to enrolling 3D Secure 2.x and integration certification (PIT), mostly done by the hosting provider.

The strategy for deploying 3D Secure is mainly driven by the fact that it reduces fraud, and consequently reduces potential for chargeback liability for the Issuer. Milestones for 3DS v2.x are not clearly announced, and test cases and certifications for vendors are not finalized, so vendors cannot provide certified 3DS 2.0/2.1 solutions. In order to protect cardholders from fraudulent online transactions, Issuers can deploy proven 3D Secure v1.0.2 solutions while EMVCo provided guidelines on how to deploy or upgrade the existing 3D Secure process to ensure a smooth transition.

The authentication method is left for choice to each Issuer. In the previous version, 3D Secure v1.0.2, static passwords were allowed. As of early 2015, ECB issued guidelines for strong authentication on eCommerce transactions. Since January 2016, when PSD2 became official, such guidelines became mandatory with up to two years for adjustment. The new specification for 3D Secure 2.1 strongly recommends two-factor strong authentication methods such as One Time Password, biometric authentication (fingerprint, face or voice recognition), etc.

3D Secure allows methods aligned with PSD2 requirements, i.e., all methods that are Strong Customer Authentication (SCA) or two-factor authentication methods. Most common methods include One Time Passwords generated by HW or SW tokens, fingerprint or face recognition biometry methods, and push notifications.

Yes. When the user goes to checkout, ACS presents a screen with an option to choose the authentication method via radio button.

The SCA requirements officially came into effect on 14 September 2019. However, on 16 October 2019, the European Banking Authority (EBA) published an Opinion allowing national regulators to delay enforcement of SCA until 31 December 2020. Most European regulators aligned with this roadmap, though timelines vary by country.

Issuing banks should check national regulations, national bank guidelines, and national PSD2 directives. Some national regulations do not accept this method as a two-factor SCA authentication method. To mitigate such requirements, an additional password or PIN can be added to OTP by SMS, making it an SCA method. Card schemes suggest using more confident methods such as fingerprint.

No. Card scheme 3D Secure programs encourage banks to apply frictionless authentication in as many cases as possible, up to 90%. Transactions should be analyzed in order to apply for SCA exemptions as defined in PSD2 requirements. Exemptions can be based on low-risk assessment, low transaction value considering counter limits, or for recurring transactions with the same amount and payee.

When choosing the most suitable authentication method, the issuing bank should consider: whether cardholders are familiar with the method, necessary resources available to their cardholders, customer segment and willingness to download mobile applications, and applicable regulations including PSD2 and local regulations. The best approach is to offer a minimum of two authentication methods and allow cardholders to select their preferred one. The best authentication rate is achieved when 3D Secure and digital channels use the same authentication methods.

(1) 3DS Requestor Initiated (3RI) payments – enabling a merchant to initiate a transaction even if the cardholder is offline. (2) Decoupled authentication – allowing cardholder authentication to occur even if the cardholder is offline. (3) Expansion of existing data elements to promote communication of pre-checkout authentication events and associated data as part of the EMV 3DS transaction from systems such as those supporting the FIDO Alliance standards.

3D Secure 2.0, released in October 2016, is designed to create a frictionless online payment experience by facilitating richer data exchange and allowing Risk-Based Authentication for low-risk transactions. It supports authentication of App-based transactions on mobile and other consumer devices, and introduces state-of-the-art authentication methods such as fingerprint, face recognition, and voice recognition. Key benefits include: mobile device web browser purchasing, integration with mobile apps, simplified user experience, elimination of sign-up process during shopping, modern biometric authentication, Risk Scoring and Risk-Based Authentication, frictionless/silent authentication, and increased conversion rate.

By using the ASEE Trides solution, Issuers are able to provide added value to their cardholders such as a user portal or mobile application which enables the cardholder to monitor their 3D Secure online transactions, maintain risk parameters such as online purchase limits, geographical restrictions, setup of SMS/push warnings in cases of unexpected purchase, lock/unlock card, define preferred authentication method, change language, etc.

First, the buyer will feel more confident knowing that additional fraud prevention was deployed. Secondly, even in case of fraud, card schemes (VISA, MasterCard) granted the so-called Liability shift for the merchant. This means that the issuing bank is liable for fraud and dispute costs, and the merchant won't suffer any losses.

In order to have efficient protection with 3D Secure, it must be implemented on the Issuer and on the Acquirer domain. Therefore, Issuers (financial institutions who issue payment cards), Acquirers, and Merchants who accept cards have to deploy the protocol.

This depends on the card scheme (VISA, MC, AMEX, Diners, etc.). Each can have different requirements and milestone deadlines, also considering geo-location. VISA does not mandate the VerifiedByVISA program, but MasterCard mandates MasterCard IdentityCheck in the EU region. However, in the EU region, PSD2 requires SCA authentication for mCommerce and eCommerce payments. By applying 3D Secure, this mandatory requirement is met.

Yes. After the transition period, latest on October 2022, 3D Secure v1.0.2 will no longer be supported by card schemes. Therefore, banks need to migrate to the new version.

Within the 3D Secure environment, even if two-factor strong authentication is applied (as required by PSD2 and 3D Secure 2.1), the Issuer is liable for chargebacks for fraudulent transactions. However, if a cardholder has to pass through another layer of authentication, it is less likely that the card is being used in a fraudulent manner. 3D Secure reduces the number of fraudulent online transactions and potential chargebacks.

Issuers must be aware that card schemes (VISA, MasterCard, etc.) are stakeholders of 3D Secure and promote its acceptance. Through 3D Secure, card schemes introduce liability shift as the main benefit for Merchants and Acquirers. This means that when a Merchant proves a transaction to be fraudulent, and the Issuer is enrolled in 3D Secure (or that particular type of card is enrolled), the Issuer is liable for the chargeback.

If you are a part of any domain, yes, you should implement a solution covering 3D Secure authentication. Cards from Issuers that do not use ACS are more often used in card-not-present transactions simply because fraudulent entities are targeting the weaker part of the chain.

top

Want to learn more about cybersecurity trends and industry news?

SUBSCRIBE TO OUR NEWSLETTER

Want to learn more about cybersecurity trends and industry news?

CyberSecurityhub

Products

Products

Products

Developers corner

About