Normal view

Direct and reverse NFC relay attacks being used to steal money | Kaspersky official blog

13 January 2026 at 21:06

Thanks to the convenience of NFC and smartphone payments, many people no longer carry wallets or remember their bank card PINs. All their cards reside in a payment app, and using that is quicker than fumbling for a physical card. Mobile payments are also secure — the technology was developed relatively recently and includes numerous anti-fraud protections. Still, criminals have invented several ways to abuse NFC and steal your money. Fortunately, protecting your funds is straightforward: just know about these tricks and avoid risky NFC usage scenarios.

What are NFC relay and NFCGate?

NFC relay is a technique where data wirelessly transmitted between a source (like a bank card) and a receiver (like a payment terminal) is intercepted by one intermediate device, and relayed in real time to another. Imagine you have two smartphones connected via the internet, each with a relay app installed. If you tap a physical bank card against the first smartphone and hold the second smartphone near a terminal or ATM, the relay app on the first smartphone will read the card’s signal using NFC, and relay it in real time to the second smartphone, which will then transmit this signal to the terminal. From the terminal’s perspective, it all looks like a real card is tapped on it — even though the card itself might physically be in another city or country.

This technology wasn’t originally created for crime. The NFCGate app appeared in 2015 as a research tool after it was developed by students at the Technical University of Darmstadt in Germany. It was intended for analyzing and debugging NFC traffic, as well as for education purposes and experiments with contactless technology. NFCGate was distributed as an open-source solution and used in academic and enthusiast circles.

Five years later, cybercriminals caught on to the potential of NFC relay and began modifying NFCGate by adding mods that allowed it to run through a malicious server, disguise itself as legitimate software, and perform social engineering scenarios.

What began as a research project morphed into the foundation for an entire class of attacks aimed at draining bank accounts without physical access to bank cards.

A history of misuse

The first documented attacks using a modified NFCGate occurred in late 2023 in the Czech Republic. By early 2025, the problem had become large scale  and noticeable: cybersecurity analysts uncovered more than 80 unique malware samples built on the NFCGate framework. The attacks evolved rapidly, with NFC relay capabilities being integrated into other malware components.

By February 2025, malware bundles combining CraxsRAT and NFCGate emerged, allowing attackers to install and configure the relay with minimal victim interaction. A new scheme, a so-called “reverse” version of NFCGate, appeared in spring 2025, fundamentally changing the attack’s execution.

Particularly noteworthy is the RatOn Trojan, first detected in the Czech Republic. It combines remote smartphone control with NFC relay capabilities, letting attackers target victims’ banking apps and cards through various technique combinations. Features like screen capture, clipboard data manipulation, SMS sending, and stealing info from crypto wallets and banking apps give criminals an extensive arsenal.

Cybercriminals have also packaged NFC relay technology into malware-as-a-service (MaaS) offerings, and reselling them to other threat actors through subscription. In early 2025, analysts uncovered a new and sophisticated Android malware campaign in Italy, dubbed SuperCard X. Attempts to deploy SuperCard X were recorded in Russia in May 2025, and in Brazil in August of the same year.

The direct NFCGate attack

The direct attack is the original criminal scheme exploiting NFCGate. In this scenario, the victim’s smartphone plays the role of the reader, while the attacker’s phone acts as the card emulator.

First, the fraudsters trick the user into installing a malicious app disguised as a banking service, a system update, an “account security” app, or even a popular app like TikTok. Once installed, the app gains access to both NFC and the internet — often without requesting dangerous permissions or root access. Some versions also ask for access to Android accessibility features.

Then, under the guise of identity verification, the victim is prompted to tap their bank card to their phone. When they do, the malware reads the card data via NFC and immediately sends it to the criminals’ server. From there, the information is relayed to a second smartphone held by a money mule, who helps extract the money. This phone then emulates the victim’s card to make payments at a terminal or withdraw cash from an ATM.

The fake app on the victim’s smartphone also asks for the card PIN — just like at a payment terminal or ATM — and sends it to the attackers.

In early versions of the attack, criminals would simply stand ready at an ATM with a phone to use the duped user’s card in real time. Later, the malware was refined so the stolen data could be used for in-store purchases in a delayed, offline mode, rather than in a live relay.

For the victim, the theft is hard to notice: the card never left their possession, they didn’t have to manually enter or recite its details, and the bank alerts about the withdrawals can be delayed or even intercepted by the malicious app itself.

Among the red flags that should make you suspect a direct NFC attack are:

  • prompts to install apps not from official stores;
  • requests to tap your bank card on your phone.

The reverse NFCGate attack

The reverse attack is a newer, more sophisticated scheme. The victim’s smartphone no longer reads their card — it emulates the attacker’s card. To the victim, everything appears completely safe: there’s no need to recite card details, share codes, or tap a card to the phone.

Just like with the direct scheme, it all starts with social engineering. The user gets a call or message convincing them to install an app for “contactless payments”, “card security”, or even “using central bank digital currency”. Once installed, the new app asks to be set as the default contactless payment method — and this step is critically important. Thanks to this, the malware requires no root access — just user consent.

The malicious app then silently connects to the attackers’ server in the background, and the NFC data from a card belonging to one of the criminals is transmitted to the victim’s device. This step is completely invisible to the victim.

Next, the victim is directed to an ATM. Under the pretext of “transferring money to a secure account” or “sending money to themselves”, they are instructed to tap their phone on the ATM’s NFC reader. At this moment, the ATM is actually interacting with the attacker’s card. The PIN is dictated to the victim beforehand — presented as “new” or “temporary”.

The result is that all the money deposited or transferred by the victim ends up in the criminals’ account.

The hallmarks of this attack are:

  • requests to change your default NFC payment method;
  • a “new” PIN;
  • any scenario where you’re told to go to an ATM and perform actions there under someone else’s instructions.

How to protect yourself from NFC relay attacks

NFC relay attacks rely not so much on technical vulnerabilities as on user trust. Defending against them comes down to some simple precautions.

  • Make sure you keep your trusted contactless payment method (like Google Pay or Samsung Pay) as the default.
  • Never tap your bank card on your phone at someone else’s request, or because an app tells you to. Legitimate apps might use your camera to scan a card number, but they’ll never ask you to use the NFC reader for your own card.
  • Never follow instructions from strangers at an ATM — no matter who they claim to be.
  • Avoid installing apps from unofficial sources. This includes links sent via messaging apps, social media, SMS, or recommended during a phone call — even if they come from someone claiming to be customer support or the police.
  • Use comprehensive security on your Android smartphones to block scam calls, prevent visits to phishing sites, and stop malware installation.
  • Stick to official app stores only. When downloading from a store, check the app’s reviews, number of downloads, publication date, and rating.
  • When using an ATM, rely on your physical card instead of your smartphone for the transaction.
  • Make it a habit to regularly check the “Payment default” setting in your phone’s NFC menu. If you see any suspicious apps listed, remove them immediately and run a full security scan on your device.
  • Review the list of apps with accessibility permissions — this is a feature commonly abused by malware. Either revoke these permissions for any suspicious apps, or uninstall the apps completely.
  • Save the official customer service numbers for your banks in your phone’s contacts. At the slightest hint of foul play, call your bank’s hotline directly without delay.
  • If you suspect your card details may have been compromised, block the card immediately.

Target employees confirm leaked code after 'accelerated' Git lockdown

13 January 2026 at 14:08
Multiple current and former Target employees confirmed that leaked source code samples posted by a threat actor match real internal systems. The company also rolled out an "accelerated" lockdown of its Git server, requiring VPN access, a day after being contacted by BleepingComputer. [...]

1980s Hacker Manifesto

13 January 2026 at 13:09

Forty years ago, The Mentor—Loyd Blankenship—published “The Conscience of a Hacker” in Phrack.

You bet your ass we’re all alike… we’ve been spoon-fed baby food at school when we hungered for steak… the bits of meat that you did let slip through were pre-chewed and tasteless. We’ve been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us willing pupils, but those few are like drops of water in the desert.

This is our world now… the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt-cheap if it wasn’t run by profiteering gluttons, and you call us criminals. We explore… and you call us criminals. We seek after knowledge… and you call us criminals. We exist without skin color, without nationality, without religious bias… and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it’s for our own good, yet we’re the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

Target's dev server offline after hackers claim to steal source code

12 January 2026 at 18:52
Hackers are claiming to be selling internal source code belonging to Target Corporation, after publishing what appears to be a sample of stolen code repositories on a public software development platform. After BleepingComputer notified Target, the files were taken offline and the retailer's developer Git server was inaccessible. [...]

Hidden Telegram proxy links can reveal your IP address in one click

12 January 2026 at 17:20
A single click on what may appear to be a Telegram username or harmless link is all it takes to expose your real IP address to attackers due to how proxy links are handled. Telegram says it will add warnings to proxy links after researchers demonstrated that such one-click interactions could reveal a Telegram user's real IP address. [...]

Prevent cloud data leaks with Microsoft 365 access reviews

12 January 2026 at 15:45
Microsoft 365 has made file sharing effortless, but that convenience often leaves organizations with little visibility into who can access sensitive data. Tenfold explains how access reviews for shared cloud content can help organizations regain visibility, reduce unnecessary permissions, and prevent data leaks in Microsoft 365. [...]

Security by Design: Why Multi-Factor Authentication Matters More Than Ever

17 December 2025 at 11:30

In an era marked by escalating cyber threats and evolving risk landscapes, organisations face mounting pressure to strengthen their security posture whilst maintaining seamless user experiences. At Thales, we recognise that robust security must be foundational – embedded into products and services by design, not bolted on as an afterthought. This principle underpins our commitment to the U.S. Cybersecurity and Infrastructure Security Agency (CISA)’s Secure-by-Design pledge, which calls on software manufacturers to establish security features like multi-factor authentication (MFA) as standard across their product portfolios.

As digital transformation accelerates and attack surfaces expand, the gap between security capabilities and emerging threats continues to widen. According to the 2025 Thales Data Threat Report, organisations are grappling with unprecedented challenges: 69% regard the fast-moving ecosystem as the most concerning GenAI security risk, whilst 83% report that strong MFA is used more than 40% of the time. This indicates both progress and significant opportunity for improvement. These findings underscore a critical reality: whilst security tools and technologies have advanced, comprehensive deployment and consistent enforcement remain essential challenges that demand immediate attention.

This blog examines the pivotal role of multi-factor authentication in modern cybersecurity strategies. We explore the fundamentals of MFA, analyse the evolving threat landscape that necessitates its adoption, and provide practical guidance on implementation. Whether you are a security professional seeking to strengthen your organisation’s defences or an individual user looking to protect personal accounts, this resource offers the insights and actionable steps needed to embrace MFA with confidence and rigour.

Understanding Multi-Factor Authentication: The Basics

Multi-factor authentication verifies your identity using two different forms of identification. Typically this involves something you know (like a password) and something you have (like a code on your phone). Think of it like using an ATM: you need both your bank card and your PIN to withdraw cash.

This dual-layer approach creates a significant barrier for attackers. Even if someone steals your password, they still can’t log in without that second factor. It’s elegantly simple, yet remarkably powerful – your password alone is no longer enough to unlock the door.

The Growing Threat Landscape: Why MFA Is No Longer Optional

Cyberattacks have grown increasingly sophisticated, with stolen passwords at the heart of many breaches. According to the 2023 Verizon Data Breach Investigations Report, nearly 49% of data breaches involved the use of stolen credentials.

MFA directly addresses this vulnerability. Our own research at Thales demonstrates the critical importance of strong authentication measures. According to the 2025 Thales Data Threat Report, 83% of organisations report that strong MFA is used more than 40% of the time, yet significant challenges remain in achieving comprehensive deployment. This data underscores both the growing recognition of MFA’s importance and the continued need for organisations to strengthen their authentication posture.

Furthermore, our 2025 Digital Trust Index – Third-Party Edition reveals a concerning reality: 40% of users reset passwords once or twice a month, highlighting the inherent weakness of password-only authentication systems. These frequent password resets not only frustrate users but also create security vulnerabilities that MFA effectively mitigates.

How MFA Defeats Common Attack Methods

MFA thwarts the most prevalent attack techniques:

Brute-force and credential stuffing attacks: These automated attacks become practically futile with MFA enabled because guessing the password isn’t enough to break in.

Phishing attacks: Even if you unwittingly hand over your password to a phisher, they still can’t access your account without the one-time code or second factor that MFA requires.

It’s no surprise that CISA’s Secure-by-Design guidelines explicitly call for making MFA a built-in, default security feature. In today’s threat landscape, MFA has evolved from a nice-to-have extra to an essential safeguard.

Thales’ Commitment: Security by Design and by Default

At Thales, we build security into our products by design, baked into our products and services. Our commitment to CISA’s Secure-by-Design pledge is reflected in how we develop features like MFA.
We already implement robust MFA across our cloud services to help safeguard your accounts and data. By requiring two forms of identification to access the Thales Cloud Security Console, we add an extra layer of protection that makes it “much harder for unauthorised users to access sensitive information”. This significantly reduces the risk of breaches and builds trust.

The Principle of Shared Responsibility

Thales’ approach recognises shared responsibility. “Security by default” means we provide secure settings and features right out of the box. However, security is also a partnership – we provide the tools, whilst you play a crucial role by using them.
We’ve made MFA available and straightforward to configure, and we actively encourage customers to use advanced authentication methods. Whilst MFA might not be mandated on all accounts by default today, we strongly recommend that you activate it. By choosing to enable MFA now, you’re not only protecting yourself immediately but also aligning with best practices that Thales and the cybersecurity community advocate globally.

Getting Started: How to Set Up MFA

Enabling multi-factor authentication on your Thales account is quick and straightforward. Here’s how:

  1. Log in and navigate to your user settings. Go to Account Settings or Profile, where you’ll find security settings for MFA management. You can find these options in the Thales Cloud Security Console setup checklist.
  2. Locate the Multi-Factor Authentication option and click to begin setup.
  3. Select your preferred MFA method: authenticator app, SMS, or email.
  4. Configure the chosen method:
    • For an authenticator app, scan the displayed QR code with your app ( MobilPASS+, Google Authenticator, Microsoft Authenticator, Authy, etc.).
    • For SMS, enter your mobile number to receive a verification code.
    • For email, a code will be sent to your registered email address.
  5. Save your backup codes. These are your safety net if you lose access to your MFA device. Store them in a secure location like a password manager.
  6. Complete and test the setup. Once verified, MFA will be enabled. Log out and log in again to ensure everything works properly.

That’s it! You’ve added a powerful extra layer of security in just a few minutes.

Choosing Your MFA Method: A Comparison

For organisations seeking a comprehensive overview of authentication options, Thales offers an extensive portfolio of MFA tokens and authenticators. Our OneWelcome Authenticators Portfolio includes FIDO2 passkeys, hardware tokens, smart cards, and software authenticators, ensuring secure access across different environments and devices . This breadth of choice allows organisations to select the authentication method best suited to their security requirements and user needs

When setting up MFA, you have several authentication options:

Authenticator App (recommended): Generates a new 6-digit code every 30 seconds. This method is very secure, works offline, and is significantly more phishing-resistant. Pros: High security, no network dependency. Cons: Requires your phone.

Text Message (SMS): Sends a one-time code to your mobile phone. Pros: Easy to use, no app required. Cons: Slightly less secure than authenticator apps due to potential SIM-swapping attacks, but still greatly improves security over no MFA. CISA recommends SMS-based authentication only as a “last resort” when more secure options aren’t available

Email Codes: Sends verification codes to your registered email. Pros: No extra device needed. Cons: Least secure option if your email is compromised. Use only if other methods aren’t feasible, and ensure your email itself has MFA.

Hardware Security Keys: Physical devices, such as Thales FIDO Security Keys that you plug in or tap to verify login. Pros: Highest level of security, phishing-resistant. Cons: Requires purchasing a device.

Which should you choose? If possible, use an authenticator app or hardware key, as these are most secure. For most users, an authenticator app strikes an excellent balance. SMS is a solid fallback, and email can work if necessary – just be aware of the security trade-offs.

Moving Beyond Passwords: Passwordless Authentication

Whilst MFA significantly strengthens security, the most forward-thinking organisations are taking the next step: eliminating passwords altogether. Passwordless authentication removes the vulnerabilities inherent in password-based systems – no passwords to steal, phish, or reuse.

Thales’ SafeNet Trusted Access empowers organisations to build comprehensive passwordless policies using FIDO2 passkeys, biometrics, and hardware authenticators. Our Passwordless 360 approach provides a detailed framework for implementing passwordless authentication across your organisation, combining security, user experience, and regulatory compliance.

Troubleshooting and Frequently Asked Questions

Q: Do I have to enter an MFA code every single time I log in?
A: Often not every time. Many systems offer the option to “remember” a device for a certain period (e.g., 14 days). This means you won’t need to enter a code each time on that trusted device. However, use this feature only on personal devices you control, not shared or public computers.

Q: I’m not receiving the MFA code, or it says the code is wrong. What should I do?
A: Common solutions include: For SMS, check your signal and that your phone number is correct in account settings. Wait a moment and click “Resend code” if available. For authenticator apps, ensure your phone’s clock is accurate, as codes are time-based. For email, check your spam folder.

Q: What if I lose access to my phone or MFA device?
A: Use your saved backup codes to log in. If you’ve lost those as well, contact Thales support for account recovery assistance.

Q: Can we use our own IdP?
A: Yes, you can leverage external IdPs like SafeNet Trusted Access by Thales, which allows you to build adaptive authentication policies and leverage a broad range of MFA options.

Q: Can I switch MFA methods?
A: Yes. You can disable MFA and re-enable it with a new method anytime through your account settings.

Q: Is MFA required?
A: Whilst not mandatory on all accounts today, we strongly recommend enabling it. It’s one of the most effective ways to protect your account.

Understanding Digital Trust: Research from Thales

Thales’ research demonstrates the critical importance of strong identity and access management. Our 2025 Digital Trust Index – Third-Party Edition reveals that 96% of third-party users face issues logging into partner systems, wasting 48 minutes a month on average. Additionally, 40% reset passwords once or twice a month – highlighting the need for more secure, passwordless methods like MFA.

The 2025 Data Threat Report further emphasises this urgency. According to our research, 83% of organisations report that strong MFA is used more than 40% of the time, yet challenges remain. As organisations adopt AI and face evolving quantum threats, robust authentication becomes even more critical.

Thales’ comprehensive Identity and Access Management solutions provide organisations with the capabilities needed to improve user experiences whilst strengthening security. From Multi-Factor Authentication and Single Sign-On to passwordless authentication and passkeys, Thales delivers the tools to make IAM processes straightforward and dependable.

Final Thought

Cybersecurity is a shared responsibility. We design secure systems, and you make them stronger by turning on protections like MFA. Enable MFA today in your Thales account settings. It takes just a few minutes and makes a significant difference.

Secure by design starts with secure choices.

The post Security by Design: Why Multi-Factor Authentication Matters More Than Ever appeared first on Blog.

Imperva Partners with TollBit to Power AI Traffic Monetization for Content Owners

16 December 2025 at 18:00

The surge in AI-driven traffic is transforming how websites manage their content. With AI bots and agents visiting sites at unprecedented rates (often scraping without permission, payment, or attribution) content owners face a critical challenge: how to protect their intellectual property while capitalizing on legitimate AI use cases.

Today, we’re excited to announce Imperva’s integration with TollBit, a groundbreaking solution that enables our Cloud Web Application Firewall (CWAF) customers to monetize traffic from AI bots and crawlers that would otherwise scrape their content without permission or compensation.

Meeting the AI Traffic Challenge

The traditional ad-supported and subscription-based content models are being disrupted by AI. This integration provides a new economic model where value flows fairly between content creators and AI developers, transforming unauthorized scraping into a sustainable revenue stream.

How Imperva and TollBit Work Together

The integration leverages Imperva’s industry-leading Web Application Firewall capabilities alongside TollBit’s analytics and monetization platform to create a comprehensive solution:

  1. Detection & Enforcement: Imperva CWAF identifies AI bot traffic at the edge, providing the critical first layer of protection.
  2. Intelligent Redirection: Using Imperva’s redirect rules, requests from AI bots are automatically redirected to a TollBit subdomain (e.g., tollbit.example.com), with CWAF returning an HTTP 302 response.
  3. Payment Gateway: The TollBit subdomain returns an HTTP 402 response code (payment required), prompting AI bot operators to obtain valid TollBit tokens for authorized access.
  4. Analytics & Insights: Through SIEM log integration, Imperva Access and Security logs flow to TollBit’s analytics engine, providing executives with clear, AI-specific analytics that show how bots are engaging with their content and the business impact of that traffic both within Tollbit and Imperva’s UMC.

Implementation Architecture

The integration requires a straightforward setup process:

  • Onboard your domain to Imperva Cloud WAF
  • Create a TollBit account and verify domain ownership via DNS TXT records
  • Configure a TollBit subdomain with appropriate DNS NS records
  • Create redirect rules in Imperva’s management console to route AI bot traffic
  • Set up AWS S3 bucket integration for log processing and analytics

To ensure compatibility with TollBit’s requirements, an AWS Lambda function prefixes dates to Imperva log file names, enabling seamless ingestion into TollBit’s analytics platform.

A Shared Vision for Fair Compensation

This partnership represents a fundamental shift in how content owners approach AI traffic. Rather than simply blocking all bots or allowing unrestricted scraping, sites now have granular control to enforce access rules and pricing on their own terms.

Content owners deserve fair compensation for how their content powers the AI ecosystem. By combining Imperva’s security capabilities with TollBit’s monetization tools, we’re enabling the transition from unauthorized scraping to sustainable, licensed transactions.

What This Means for Imperva Customers

With this integration, Imperva CWAF customers gain:

  • Robust protection against unauthorized AI scraping at the application layer
  • Complete visibility into AI traffic patterns and behaviors through dedicated analytics
  • Flexible control to decide which AI agents can access content and under what conditions
  • New revenue streams that turn scraping attempts into legitimate, paid transactions

The agent economy is here, and autonomous AI visitors are becoming a permanent fixture of web traffic. With Imperva and TollBit, you can ensure these interactions happen on your terms—fairly, transparently, and profitably.

Get Started

If you’re an Imperva Cloud WAF customer and want to activate the integration:

TollBit is free for publishers and websites so you can be up and running in no time.

Learn more about how Imperva’s integration with TollBit can help you protect and monetize your content in the AI era.

The post Imperva Partners with TollBit to Power AI Traffic Monetization for Content Owners appeared first on Blog.

The Privacy Gap in API Security: Why Protecting APIs Shouldn’t Put Your Data at Risk

10 December 2025 at 17:39

The more critical APIs become, the more sensitive data they carry identities, payment details, health records, customer preferences, tokens, keys, and more.

And this is where organizations face a painful, often invisible problem:

To protect APIs, many organizations end up exposing the very data they are trying to secure.

Most API security tools still rely on raw-payload logging, traffic replay, or shipping full request bodies into external analytics systems. That means sensitive customer data:

  • Leaves controlled environments
  • Gets stored in multiple systems
  • Crosses borders without intention
  • Lands in tools not designed to hold PII
  • Multiplies breach risk and regulatory pressure

This creates a direct conflict between security, privacy, and compliance, and businesses are caught in the middle.

The Real-World Impact: When Privacy Becomes a Security Liability

Across industries – financial services, retail, healthcare, travel, public sector, the story repeats:

1. Breach blast radius expands

The more systems that hold raw API payloads, the bigger the impact when any one of them is compromised.

2. Compliance becomes harder, not easier

GDPR, CCPA, HIPAA, PCI, and emerging data-sovereignty regulations penalize:

  • unnecessary data retention
  • cross-border data transfers
  • third-party exposure
  • lack of data-minimization controls

Most API security tools inadvertently violate all four.

3. Data residency rules block API security deployments

Organizations operating in multiple regions can’t centralize raw API data in a single cloud service, but many tools require doing exactly that.

4. Dev and QA environments become privacy risks

When security tests are based on production payload replays, sensitive data leaks into non-production systems.

5. Security teams lose visibility if they avoid raw logging

Many leaders try to “lock down” data flows, but that often leaves API blind spots, making it harder to detect business logic abuse, scraping, or session-based attacks.

This is the API privacy paradox:
You either weaken privacy to strengthen security or weaken security to preserve privacy.

The Industry Approach Is Broken

The traditional API security model makes three flawed assumptions:

  1. You must log or store raw payloads to get visibility.
  2. You must centralize traffic for analytics.
  3. You must replay production data to test API security.

These assumptions create privacy exposure, compliance failure, and operational friction.

Imperva Solves This by Rethinking the Architecture

Imperva’s privacy-first, local-first platform was built around a core belief:

API security should not require exposing sensitive data, ever.

The architecture flips the traditional model:

1. Inspect at the PoP (where traffic lives)

Traffic is parsed in-memory at the Point-of-Presence closest to the application, SaaS PoP or on-prem.

Raw values never leave the PoP.

2. Convert sensitive values into privacy-safe artifacts

Classification + hashing replaces raw payloads with:

  • label
  • schema fragments
  • one-way irreversible hashes
    This is the only data that ever moves upstream.

3. Detect and respond using metadata only

Anomaly detection uses metadata such as:

  • data labels
  • schema context
  • session identifiers
  • hashed tokens

No raw content is needed or exposed.

4. Enforce using hashes, not identities

Hash-based enforcement enables:

  • per-session blocking
  • token-level mitigation
  • behavior-based decisions
    without seeing or sharing the sensitive value behind the hash.

5. Same privacy guarantees across all deployments

Cloud, on-prem, hybrid – the mechanics never change.

What This Means for the Business

This is where Imperva’s architecture translates directly into measurable, enterprise-wide value:

✔ Smaller blast radius = lower breach liability

Fewer systems hold PII, drastically reducing what attackers can steal and what you must disclose.

✔ Faster compliance alignment

Local data processing and zero raw persistence align with GDPR, HIPAA minimum-necessary, and sovereignty rules.

✔ Real-time protection with zero added exposure

Inline, in-PoP inspection gives detection teams full visibility without raw payload retention.

✔ Safer automation in Dev/QA

Privacy-aware test artifacts eliminate the risk of production PII leaking into pipelines.

✔ Reduced third-party risk

Vendors never receive raw payloads, only metadata and hashes.

✔ A future-proof privacy posture

As regulatory pressure increases, architectures like this become mandatory, not optional.

Why This Whitepaper Matters

This whitepaper breaks down exactly how Imperva delivers production-grade API protection while preserving privacy, with clear explanations and practical examples.

You’ll learn:

  • How to get deep visibility without storing raw payloads
  • Why in-PoP processing reduces exposure and simplifies compliance
  • How hash-based enforcement protects identities while enabling precise blocking
  • How to design a privacy-first architecture that works across hybrid/multi-cloud

In other words:
If you need to secure APIs and meet privacy, residency, or compliance requirements – this is essential reading.

Ready to See How Privacy-First API Security Really Works?

Download the whitepaper and learn how Imperva protects APIs without exposing sensitive data.

The post The Privacy Gap in API Security: Why Protecting APIs Shouldn’t Put Your Data at Risk appeared first on Blog.

❌