Reading view

AWS European Sovereign Cloud achieves first compliance milestone: SOC 2 and C5 reports plus seven ISO certifications

In January 2026, we announced the general availability of the AWS European Sovereign Cloud, a new, independent cloud for Europe entirely located within the European Union (EU), and physically and logically separate from all other AWS Regions. The unique approach of the AWS European Sovereign Cloud provides the only fully featured, independently operated sovereign cloud backed by strong technical controls, sovereign assurances, and legal protections designed to meet the sensitive data needs of European governments and enterprises.

One of the foundational components of how AWS European Sovereign Cloud enables verifiable trust of technical controls and delivers assurance is through our compliance programs and assurance frameworks. These programs help customers understand the robust controls in place at AWS European Sovereign Cloud to maintain security and compliance of the cloud. To meet the needs of our customers, we committed that the AWS European Sovereign Cloud will maintain key certifications such as ISO/IEC 27001:2022, System and Organization Controls (SOC) reports, and Cloud Computing Compliance Criteria Catalogue (C5) attestation, all validated regularly by independent auditors to assure our controls are designed appropriately, operate effectively, and can help customers satisfy their compliance obligations.

Today, AWS European Sovereign Cloud is pleased to announce that SOC 2 and C5 Type 1 attestation reports, along with seven key ISO certifications (ISO 27001:2022, 27017:2015, 27018:2019, 27701:2019, 22301:2019, 20000-1:2018, and 9001:2015) are now available. The attestation reports cover 69 AWS services operating within the AWS European Sovereign Cloud, while the certificates have integrated the AWS European Sovereign Cloud region into the global AWS Management Systems. This achievement marks a pivotal first step in our journey to establish the AWS European Sovereign Cloud as a trusted and compliant cloud for European organizations. By securing these foundational certifications and attestation reports early in our implementation, we are demonstrating our commitment to earning customer trust. AWS European Sovereign Cloud customers in Germany and across Europe can now run their applications with enhanced assurance and confidence that our infrastructure aligns with internationally recognized security standards and the AWS European Sovereign Cloud: Sovereign Reference Framework (ESC-SRF). These certifications and attestation reports provide independent validation of our security controls and operational practices, demonstrating our commitment to meeting the heightened expectations towards cloud service providers. Beyond compliance, these certifications and reports help customers meet regulatory requirements and innovate with confidence.

SOC 2 Type 1 report

SOC reports are independent third-party examinations that show how AWS European Sovereign Cloud meets compliance controls and sovereignty objectives. The AWS European Sovereign Cloud SOC 2 report addresses three critical AICPA Trust Services Criteria: Security, Availability, and Confidentiality and includes internal controls mapped to the ESC-SRF. The ESC-SRF establishes sovereignty criteria across key domains including governance independence, operational control, data residency, and technical isolation. As part of the SOC 2 Type 1 attestation, independent third-party auditors have validated suitability of the design and implementation of our controls addressing measures such as independent European Union (EU) corporate structures, operation by EU-resident AWS personnel, strict residency requirements for Customer Content and Customer-Created Metadata, and separation from all other AWS Regions. The ESC-SRF controls in our SOC 2 report show customers how AWS delivers on its sovereignty commitments.

C5 Type 1 report

C5 is a German Government-backed attestation scheme introduced in Germany by the Federal Office for Information Security (BSI) and represents one of the most comprehensive cloud security standards in Europe. The AWS European Sovereign Cloud C5 Type 1 report provides customers with independent third-party attestation on the suitability of the design and implementation of our controls to meet both C5 basic criteria and C5 additional criteria.

The basic criteria establish fundamental security requirements for cloud service providers, covering areas such as organization of information security, human resources security, asset management, access control, cryptography, physical security, operations security, communications security, system acquisition and development, supplier relationships, incident management, business continuity, and compliance. The additional criteria address enhanced requirements for handling sensitive data and critical applications, making this attestation particularly valuable for AWS European Sovereign Cloud customers with stringent data security and sovereignty requirements.

Key ISO certifications

AWS European Sovereign Cloud region has achieved successful onboarding to seven key ISO certifications that collectively demonstrate comprehensive operational excellence:

These certifications confirm that AWS European Sovereign Cloud region has been integrated into comprehensive frameworks for managing security, privacy, continuity, service delivery, and quality, helping to ensure sensitive information remains secure, services remain available, and operations meet the highest standards through systematic risk management processes and continuous improvement practices.

How to access the reports

To access SOC 2, C5 reports and ISO certifications, customers should sign in to their AWS European Sovereign Cloud account and navigate to AWS Artifact in the AWS Management Console. AWS Artifact is a self-service portal that provides on-demand access to AWS compliance reports and certifications.

We recognize that compliance is not a destination but a continuous journey, and these initial SOC 2, C5 reports and ISO certifications represent the beginning of our certification portfolio. They lay the essential groundwork upon which we will continue to build to meet AWS European Sovereign Cloud customers’ compliance needs as they continue to evolve. As we expand our compliance coverage in the months ahead, customers can be confident that security, transparency, and regulatory alignment have been part of the very DNA of the AWS European Sovereign Cloud design from day one. To learn more about our compliance and security programs, visit AWS European Sovereign Cloud Compliance, or reach out to your AWS European Sovereign Cloud account team.

Security and compliance is a shared responsibility between AWS European Sovereign Cloud and the customer. For more information, see the AWS Shared Security Responsibility Model.

If you have feedback about this post, submit comments in the Comments section below.

Julian Herlinghaus

Julian Herlinghaus

Julian is a Manager in AWS Compliance & Security Assurance based in Berlin, Germany. He is the third-party audit program lead for EMEA and has worked on compliance and assurance for the AWS European Sovereign Cloud. He previously worked as an information security department lead of an accredited certification body and has multiple years of experience in information security and security assurance and compliance.

Tea Jioshvili

Tea Jioshvili

Tea is a Manager in AWS Compliance & Security Assurance based in Berlin, Germany. She leads various third-party audit programs across Europe. She previously worked in security assurance and compliance, business continuity, and operational risk management in the financial industry for 20 years.

Atul Patil

Atulsing Patil
Atulsing is a Compliance Program Manager at AWS. He has 29 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, ISO 42001 Lead Auditor, ISO 27001 Lead Auditor, HITRUST CSF, Archer Certified Consultant, and AWS CCP.

  •  

Security is a team sport: AWS at RSAC 2026 Conference

The RSAC 2026 Conference brings together thousands of professionals, practitioners, vendors, and associations to discuss issues covering the entire spectrum of cybersecurity—a place where innovation meets collaboration and the industry’s brightest minds converge to shape its future. This March, Amazon Web Services (AWS) returns to the annual RSAC Conference in San Francisco to share how unifying security and data empowers teams to protect AI-driven workloads while maximizing existing security investments.

Experience innovation at the AWS booth

Visit us at booth S-0466 in South Expo to experience three interactive demo kiosks:

  • The AWS Security Solutions kiosk features live demonstrations of AWS security services including new launches showcasing the latest cloud security innovations and how they work with partner solutions to provide comprehensive protection for your organization. Meet with AWS Security Specialists to discuss your specific security challenges.
  • The AWS Security Partners kiosk showcases live demos from more than 20 AWS Partners showcasing how these partners integrate seamlessly with AWS to address your most critical security challenges.
  • The Humanoid Security Guardian kiosk offers an interactive AI-powered experience that generates customized well-architected framework guides, delivered through QR code for implementation reference.

Partner Passport program: Stop by the AWS booth to pick up your playbook to start exploring integrated AWS Partner security solutions across the show floor. Visit participating partner booths throughout the conference to learn about joint solutions that combine AWS infrastructure with partner innovations. After you’ve received all partner booth visit stamps, you’ll receive AWS swag and entry into a daily raffle to win an exclusive prize.

Beyond the booth: Deep dive sessions and hands-on workshops

AWS security experts will be sharing insights across four sessions throughout RSAC 2026 Conference. These sessions cover the most pressing challenges in AI security, from privacy-by-design principles to preparing for AI-native incidents. Don’t miss learning directly from AWS experts in these sessions.

Privacy by Design in the AI Era | Reserve a seat
Monday, March 23, 2026 | 8:30 AM–9:20 AM PDT
Attendees will learn how to design AI systems with privacy embedded from the start. This session will cover data minimization strategies, architectural patterns for consent-aware decision-making, and practical approaches for building privacy-respecting AI in dynamic environments. Speakers: Juan David Alvares Builes, Senior Security Consultant, Amazon Web Services and Zully Romero, Security and Solutions Architect, Bancolombia.

Trusted Identity Propagation for Autonomous Agents Across Cloud & SaaS | Reserve a seat
Monday, March 23, 2026 | 9:40 AM–10:30 AM PDT
This session will explore trusted identity propagation for autonomous agents across cloud, SaaS, and multi-domain environments. Compare AWS, Azure, Apple, and Cloudflare approaches, focusing on identity continuity, credential management, and privacy-aware designs for secure, agent-driven enterprise systems. Speakers: Swara Gandhi, Senior Solutions Architect, Amazon Web Services and Vijeth Lomada, Lead AI Engineer, Adobe.

How to Secure Containerized Applications from Supply Chain Attacks | Reserve a seat
Monday, March 23, 2026 | 1:10 PM–2:00 PM PDT
Software supply chain attacks target development pipelines to inject malicious code into container images and dependencies. This session demonstrates how to secure containerized applications through automated scanning, Software Bill of Materials (SBOM) generation, and image signing. Learn to implement security controls in CI/CD pipelines using open-source and commercial solutions. Speakers: Patrick Palmer, Principal Security, Solutions Architect, Amazon Web Services and Monika Vu Minh, Quantitative Technologist, Qube Research & Technologies

From Prompt to Pager: Preparing for AI-Native Incidents Now | Reserve a seat
Wednesday, March 25, 2026 | 1:15 PM–2:05 PM PDT
AI incidents start as prompts and end as actions like code edits, SQL writes, workflow changes, yet most playbooks are not ready. This talk will explain why AI incidents differ, show where classic guardrails miss, and share field-tested steps to prepare now: log model-generated actions, add pre/post-conditions, capture provenance, limit blast radius, and rehearse one AI-native scenario. Speaker: Aviral Srivastava, Security Engineer, Amazon

AWS activities and events

AWS will host events at Cloud Village, an interactive community space where security practitioners explore offensive and defensive cloud security through hands-on activities, technical talks, and collaborative discussions. AWS is hosting two technical workshops that provide hands-on practical skills security teams can implement immediately. AWS has also crafted multiple capture the flag (CTF) community challenges at both RSAC 2026 Conference and BSidesSF that advance the broader security community’s capabilities – built by the same team behind the AWS Vulnerability Disclosure Program, where researchers can responsibly report security concerns directly to AWS. Cloud Village will be located in Moscone South, Level 2, Room 204 and is open to All Access Pass and Expo Plus Pass holders.

Finally, you can also join us at a customer soiree AWS is co-hosting with CrowdStrike, on Wednesday, March 25 at The Mint, for an evening of discovery, where artists, thinkers, and leaders gather to challenge convention, shape the future and have some fun. Register to join us

If you’re looking for opportunities for meaningful connections across the security community, AWS is hosting several events including;

Join us in San Francisco

Whether you’re exploring how to secure AI workloads, seeking to unify security across distributed environments, or looking to optimize your security data strategy, the AWS team at RSAC 2026 Conference is ready to collaborate. Visit booth S-0466 in South Expo, attend our technical workshops at the Cloud Village, or join AWS-led sessions. You can also schedule time to meet with AWS experts for more in-depth discussions. Together, we’ll demonstrate that when it comes to cybersecurity, we’re all on the same team.

Learn more about AWS Security solutions at aws.amazon.com/security
See you in San Francisco, March 23–26, 2026.

Idaliz Seymour Idaliz Seymour
Idaliz is a Product Marketing Manager at AWS Security, specializing in helping organizations understand the value of network and application protection in the cloud. In her free time, you’ll find her reading or boxing.
  •  

When your DDoS mitigation provider goes down: Why traffic control can’t be outsourced

Since the headline-grabbing outages of 2021, we’ve had recurring conversations with large enterprises asking some version of the same question.

Do we really want our CDN, security, and routing control to live in the same place?

This issue of control has become more urgent after a series of well‑publicized, multi‑hour outages across major cloud‑based DDoS protection and security platforms. These incidents are rare but appear to be increasing in frequency. And when they happen, they expose architectural decisions many organisations haven’t revisited in years. The fact is that architectures assumed providers would never fail. Reality proved them wrong.

The concern isn’t whether cloud DDoS mitigation works. At scale, it does. The issue is control: whether customers retain the ability to reroute traffic independently if the provider itself goes down.

Many DDoS protection services simplify onboarding by originating customer prefixes and returning traffic via static paths. Under normal conditions, this works. During a provider outage, especially one affecting routing or orchestration, customers may lose the ability to reroute traffic
independently. Recovery depends on provider‑side changes at the worst possible moment.

That’s when a DDoS mitigation service can become a single point of failure.

Protection and control are different problems

One thing we consistently hear from network and security teams is that DDoS attack mitigation and traffic control are often treated as the same problem. They aren’t.

Resilient architectures separate them:

Function Who Should Control It
Attack mitigation DDoS provider
Traffic routing decisions Customer network

The Internet already provides a mechanism to enforce this separation: the Border Gateway Protocol (BGP). This is the Internet’s routing protocol; it determines how traffic is directed between the networks.

So, the real question isn’t whether to use cloud‑based DDoS protection. It’s whether that protection operates with your routing policy, or instead of it.

Resilient architectures treat attack mitigation and traffic control as separate concerns. Providers absorb DDoS attacks. Customers retain routing authority using BGP, enabling them to decide how traffic flows during failures.

When customers control BGP, outages take on a different character. They become routing events, not service outages. Traffic can be redirected faster, the blast radius is reduced, and network teams respond using familiar controls instead of escalation paths.

Designing for the inevitable

No provider is immune to failure. CDNs, hyperscalers, and DDoS mitigation services all operate complex, global control planes.

Resilience doesn’t come from assuming outages won’t happen. It comes from designing so that when they do, customers still control the outcome.

That’s why more organizations are adopting architectures where:

  • DDoS protection is cloud‑delivered
  • Routing authority remains customer‑owned
  • BGP is the final decision layer for traffic steering

This approach preserves the benefits of cloud‑scale mitigation while avoiding the creation of new single points of failure.

A practical next step

If you’re rethinking your DDoS architecture, your best starting point isn’t a product demo; it’s an architectural review. Here are some questions to ask yourself:

  • Who originates your prefixes today?
  • How quickly can you reroute traffic if a provider is unavailable?
  • What dependencies exist between mitigation availability and network availability?

Those answers usually reveal more than any outage postmortem.

On the Internet, control of routing is control of availability, and we think that control should always remain in customer’s hands.

Want to discuss what customer‑controlled DDoS protection looks like in practice? Get in touch with Thales to review your architecture.

The post When your DDoS mitigation provider goes down: Why traffic control can’t be outsourced appeared first on Blog.

  •  

AWS Security Hub is expanding to unify security operations across multicloud environments

After talking with many customers, one thing is clear: the security challenge has not gotten easier. Enterprises today operate across a complex mix of environments, including on-premises infrastructure, private data centers, and multiple clouds, often with tools that were never designed to work together. The result is enterprise security teams spend more time managing tools than managing risk, making it harder to stay ahead of threats across an increasingly complex environment.

At Amazon Web Service (AWS), we believe security should be simple, integrated, and built for the way enterprises actually operate. This belief is what drove us to reimagine AWS Security Hub, delivering full-stack security through a single experience, and this vision is driving our next chapter.

Building on a foundation of unified security

We transformed Security Hub into a unified security operations solution by bringing together AWS security services, including Amazon GuardDuty, Amazon Inspector, AWS Security Hub Cloud Security Posture Management (Security Hub CSPM), and Amazon Macie, into a single experience that automatically and continuously analyzes security signals across threats, vulnerabilities, misconfigurations, and sensitive data. Security Hub delivers a common foundation, bringing together findings from across your AWS environment so your security team spends less time translating signals and more time acting on them. Built on top of that foundation, a unified operations layer gives security teams near real-time risk analytics, automated analysis, and prioritized insights, helping them focus on what matters most, at scale.

We also introduced new capabilities (the Extended plan) that simplify how enterprises procure, deploy, and integrate a full-stack security solution across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. Now, customers can use Security Hub to expand their security portfolio through a curated selection of AWS Partner solutions (at launch: 7AI, Britive, CrowdStrike, Cyera, Island, Noma, Okta, Oligo, Opti, Proofpoint, SailPoint, Splunk (a Cisco company), Upwind, and Zscaler), all through one unified experience. With AWS as the seller of record, you benefit from pay-as-you-go pricing, a single bill, and no long-term commitments. Our goal is simple: unified security, everywhere your enterprise operates.

Freedom to innovate, wherever your workloads are

At AWS, interoperability means giving customers the freedom to choose solutions that best suit their needs, and the ability to use them wherever their workloads run. But freedom to innovate across multicloud environments also means that it is critical to secure them consistently, and without adding operational complexity.

What’s coming for Security Hub

In the coming months, we are expanding Security Hub with new multicloud capabilities that extend unified security operations beyond AWS. The foundation of this expansion is a common data layer that unifies security signals from wherever your workloads run. On top of that, a unified policy and operations layer delivers consistent posture management, exposure analysis, and risk prioritization, so your security team operates from a single view of risk rather than a fragmented collection of consoles.

Security Hub will deliver unified risk analytics that surface critical risks across your multicloud estate. You’ll be able to manage cloud security posture with Security Hub CSPM checks that give you consistent posture visibility, and extend vulnerability management with expanded Amazon Inspector capabilities, including virtual machine scanning, container image scanning, and serverless scanning. Security Hub will also deliver external network scanning that enriches security findings with context about internet-facing exposure across your multicloud environment, including for resources not running in AWS.

The result is more comprehensive risk coverage across your enterprise. It’s about giving your security team a single, unified experience to detect and respond to risks, wherever you operate.

Security as a business enabler

The security leaders I speak with aren’t just asking for better tools. They’re asking for a way to get ahead of risk, not just manage it. They want security that keeps pace with the business, not security that slows it down.

That’s the vision behind AWS Security Hub: unified security through a single, integrated security operations experience, built on a common data foundation, powered by intelligent analytics, and delivered through a consistent operations layer, to help reduce security risk, improve team productivity, and strengthen security operations across AWS and beyond.

Our multicloud expansion is underway, and we are just getting started.

You can learn more at aws.amazon.com/security-hub, or visit us at the AWS booth (S-0466) at RSA Conference, March 23–26 in San Francisco.

Gee Rittenhouse Gee Rittenhouse
Gee is the Vice President of Security Services at AWS, overseeing key services including Security Hub, GuardDuty, and Inspector. He holds a PhD from MIT and brings extensive leadership experience across enterprise security and cloud. He previously served as CEO of Skyhigh Security and Senior Vice President and General Manager of Cisco’s Security Business Group, where he was responsible for Cisco’s worldwide cybersecurity business.
  •  

How the National Cyber Strategy Secures Our Digital Way of Life

A Pivotal Moment for National Security

As the digital landscape undergoes profound shifts, the recently released National Cyber Strategy provides the essential foundation for enduring American leadership. By prioritizing the disruption of hostile actors, future-proofing networks, accelerating quantum readiness, and securing the AI frontier, the strategy provides the strategic clarity necessary to protect our digital way of life from sophisticated adversaries. Palo Alto Networks commends National Cyber Director Sean Cairncross for his leadership and looks forward to working with the administration to operationalize this strategy.

Each pillar of the strategy galvanizes meaningful action to advance our collective defense:

Shape Adversary Behavior (Pillar 1)

This signals a decisive shift toward the proactive disruption of malicious actors. The Trump Administration has made clear that the U.S. Government should impose real costs on adversaries to change their behavior. While the private sector is already executing discrete disruptions against malicious actors, coordination has historically been fragmented. The strategy identifies that increased collaboration with private sector entities, who possess unique insight into adversary behavior, can in turn enable more impactful deterrence.

Promote Common Sense Regulation (Pillar 2)

The strategy appropriately recognizes that complexity is the enemy of security. A focus on measurable improvements in cyber outcomes (versus check-the-box compliance exercises) collectively makes us all safer. While much attention is rightfully paid toward harmonizing incident reporting requirements, which Palo Alto Networks wholeheartedly supports, let’s not stop there. The federal government can lead by example by consolidating and streamlining federal government software compliance certifications. For example, there should be logical reciprocity between FedRAMP High and DoW IL-5 certifications.

Modernize and Secure Federal Government Networks (Pillar 3)

In addition to the necessary attention on AI-powered cyber defense, cloud security and zero trust network architecture, Palo Alto Networks applauds the discrete focus on quantum-safe security ahead of “Q-Day,” the point where quantum computing capabilities will compromise legacy public key encryption that has underpinned cybersecurity for decades. As Federal CISO Mike Duffy recently stated, "Modernization without considering PQC readiness or cryptographic agility is really creating technical debt in the future, something that we don’t want to see ever.”

To address this challenge, Palo Alto Networks provides a structured quantum-safe framework organized into four stages:

  • Continuous Discovery – Automating ecosystem ingestion to identify cryptographic dependencies.
  • Risk Assessment & Prioritization – Evaluating vulnerabilities to establish a data-driven remediation roadmap.
  • Comprehensive Remediation – Executing the transition to post-quantum algorithms across the architecture.
  • Governance & Crypto-Hygiene – Maintaining long-term visibility and management.

The bottom line is that 2035 is too late. Quantum readiness must accelerate today, and this strategy will set a critical North Star to drive the necessary urgency.

Secure Critical Infrastructure (Pillar 4)

Critical infrastructure resilience is central to our homeland security, economic security, public health and safety. Unfortunately, critical infrastructure entities are increasingly under assault from emboldened cyber adversaries.

In fact, Palo Alto Networks research shows some form of operational disruption in up to 86% of major cyber incidents. Our 2026 Global Incident Response Report underscores another sobering reality: These entities are under assault from all angles. In 87% of cyber incidents, attacks targeted multiple attack surfaces, which spanned the network, cloud, endpoints and identity.

Recognizing that you can’t secure what you can’t see, we need a national-level effort to identify, prioritize and harden the critical infrastructure that the American people depend upon. This strategy puts an important marker in the ground to revitalize those efforts.

Sustain Superiority in Critical and Emerging Technologies (Pillar 5)

Palo Alto Networks was pleased to see the strategy reinforces the core tenets of the AI Action Plan, emphasizing that "secure-by-design" principles for AI technologies are non-negotiable and that AI adoption and AI security can and must be inexorably linked.

Enterprises should be able to deploy AI confidently without fear of data leakage, model tampering or rogue AI agents. However, despite our research showing an 88% success rate of “jailbreaking” techniques against widely deployed AI models, only 6% of organizations currently have an AI security strategy. It’s time to flip this paradigm and put defenders back in the driver’s seat in this AI-first moment.

To support this emerging consensus around the importance of promoting AI security, we developed the Secure AI by Design Policy Roadmap. This framework provides a four-part construct to evaluate the evolving dimensions of threats to AI systems. Palo Alto Networks is also proud to make its comprehensive AI security suite, Prisma® AIRS™, available to all federal agencies at substantial discounts through GSA’s OneGov Initiative.

Build Talent and Capacity (Pillar 6)

Recognizing America’s cyber workforce as a “strategic asset,” the strategy calls for a pragmatic and accessible pipeline for developing talent. The explicit recognition that we should take advantage of existing avenues across government, industry and academia is important. For example, Palo Alto Networks is proud of the impact of its Cybersecurity Academy – that provides free, NIST Framework-aligned curricula covering essential domains, such as cybersecurity fundamentals, enterprise and network security, cloud security, security operations and the AI/cybersecurity nexus.

Resources like this, and those for other entities, can form the basis of a renewed focus on cyber talent development.

Turning Strategic Vision Into Action

Palo Alto Networks views itself as more than a cybersecurity vendor. We see ourselves as an integrated national security partner of the federal government at a moment when defending our digital way of life demands all of us working together. To that end, we are ready to do our part to turn strategic vision into action.

This strategy should be applauded. Let’s roll up our sleeves and get to work.

The post How the National Cyber Strategy Secures Our Digital Way of Life appeared first on Palo Alto Networks Blog.

  •  

AWS completes the 2026 annual Dubai Electronic Security Centre (DESC) certification audit

We’re excited to announce that Amazon Web Services (AWS) has completed the annual Dubai Electronic Security Centre (DESC) certification audit to operate as a Tier 1 Cloud Service Provider (CSP) for the AWS Middle East (UAE) Region.

This alignment with DESC requirements demonstrates our continued commitment to adhere to the heightened expectations for CSPs. Government customers of AWS can run their applications in AWS Cloud-certified Regions with confidence.

The AWS compliance to the DESC Framework requirements were validated by an independent third-party auditor (BSI) prior to issuance of a renewed certificate by DESC. The updated DESC CSP certificate is available through AWS Artifact, and is valid for one year to January 22, 2027. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

The certification includes the following 10 additional services in scope, for a total of 108 services:

This is a 10% increase in the number of services in the Middle East (UAE) Region that are in scope of the DESC CSP certification.

AWS strives to continuously bring services into the scope of its compliance programs to help you meet your architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. You can also reach out to your AWS account team if you have any questions or feedback about DESC compliance.

To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

If you have feedback about this post, submit comments in the Comments section below

Tariro Dongo Tariro Dongo
Tari is a Security Assurance Program Manager at AWS, based in London. Tari is responsible for third-party and customer audits, attestations, certifications, and assessments across EMEA. Previously, Tari worked in security assurance and technology risk in the big four and financial services industry over the last 15 years.
  •  

How to disable unwanted AI assistants and features on your PC and smartphone | Kaspersky official blog

If you don’t go searching for AI services, they’ll find you all the same. Every major tech company feels a moral obligation not just to develop an AI assistant, integrated chatbot, or autonomous agent, but to bake it into their existing mainstream products and forcibly activate it for tens of millions of users. Here are just a few examples from the last six months:

On the flip side, geeks have rushed to build their own “personal Jarvises” by renting VPS instances or hoarding Mac minis to run the OpenClaw AI agent. Unfortunately, OpenClaw’s security issues with default settings turned out to be so massive that it’s already been dubbed the biggest cybersecurity threat of 2026.

Beyond the sheer annoyance of having something shoved down your throat, this AI epidemic brings some very real practical risks and headaches. AI assistants hoover up every bit of data they can get their hands on, parsing the context of the websites you visit, analyzing your saved documents, reading through your chats, and so on. This gives AI companies an unprecedentedly intimate look into every user’s life.

A leak of this data during a cyberattack — whether from the AI provider’s servers or from the cache on your own machine — could be catastrophic. These assistants can see and cache everything you can, including data usually tucked behind multiple layers of security: banking info, medical diagnoses, private messages, and other sensitive intel. We took a deep dive into how this plays out when we broke down the issues with the AI-powered Copilot+ Recall system, which Microsoft also planned to force-feed to everyone. On top of that, AI can be a total resource hog, eating up RAM, GPU cycles, and storage, which often leads to a noticeable hit to system performance.

For those who want to sit out the AI storm and avoid these half-baked, rushed-to-market neural network assistants, we’ve put together a quick guide on how to kill the AI in popular apps and services.

How to disable AI in Google Docs, Gmail, and Google Workspace

Google’s AI assistant features in Mail and Docs are lumped together under the umbrella of “smart features”. In addition to the large language model, this includes various minor conveniences, like automatically adding meetings to your calendar when you receive an invite in Gmail. Unfortunately, it’s an all-or-nothing deal: you have to disable all of the “smart features” to get rid of the AI.

To do this, open Gmail, click the Settings (gear) icon, and then select See all settings. On the General tab, scroll down to Google Workspace smart features. Click Manage Workspace smart feature settings and toggle off two options: Smart features in Google Workspace and Smart features in other Google products. We also recommend unchecking the box next to Turn on smart features in Gmail, Chat, and Meet on the same general settings tab. You’ll need to restart your Google apps afterward (which usually happens automatically).

How to disable AI Overviews in Google Search

You can kill off AI Overviews in search results on both desktops and smartphones (including iPhones), and the fix is the same across the board. The simplest way to bypass the AI overview on a case-by-case basis is to append -ai to your search query — for example, how to make pizza -ai. Unfortunately, this method occasionally glitches, causing Google to abruptly claim it found absolutely nothing for your request.

If that happens, you can achieve the same result by switching the search results page to Web mode. To do this, select the Web filter immediately below the search bar — you’ll often find it tucked away under the More button.

A more radical solution is to jump ship to a different search engine entirely. For instance, DuckDuckGo not only tracks users less and shows little ads, but it also offers a dedicated AI-free search — just bookmark the search page at noai.duckduckgo.com.

How to disable AI features in Chrome

Chrome currently has two types of AI features baked in. The first communicates with Google’s servers and handles things like the smart assistant, an autonomous browsing AI agent, and smart search. The second handles locally more utility-based tasks, such as identifying phishing pages or grouping browser tabs. The first group of settings is labeled AI mode, while the second contains the term Gemini Nano.

To disable them, type chrome://flags into the address bar and hit Enter. You’ll see a list of system flags and a search bar; type “AI” into that search bar. This will filter the massive list down to about a dozen AI features (and a few other settings where those letters just happen to appear in a longer word). The second search term you’ll need in this window is “Gemini“.

After reviewing the options, you can disable the unwanted AI features — or just turn them all off — but the bare minimum should include:

  • AI Mode Omnibox entrypoint
  • AI Entrypoint Disabled on User Input
  • Omnibox Allow AI Mode Matches
  • Prompt API for Gemini Nano
  • Prompt API for Gemini Nano with Multimodal Input

Set all of these to Disabled.

How to disable AI features in Firefox

While Firefox doesn’t have its own built-in chatbots and hasn’t (yet) tried to force upon users agent-based features, the browser does come equipped with smart-tab grouping, a sidebar for chatbots, and a few other perks. Generally, AI in Firefox is much less “in your face” than in Chrome or Edge. But if you still want to pull the plug, you’ve two ways to do it.

The first method is available in recent Firefox releases — starting with version 148, a dedicated AI Controls section appeared in the browser settings, though the controls are currently a bit sparse. You can use a single toggle to completely Block AI enhancements, shutting down AI features entirely. You can also specify whether you want to use On-device AI by downloading small local models (currently just for translations) and configure AI chatbot providers in sidebar, choosing between Anthropic Claude, ChatGPT, Copilot, Google Gemini, and Le Chat Mistral.

The second path — for older versions of Firefox — requires a trip into the hidden system settings. Type about:config into the address bar, hit Enter, and click the button to confirm that you accept the risk of poking around under the hood.

A massive list of settings will appear along with a search bar. Type “ML” to filter for settings related to machine learning.

To disable AI in Firefox, toggle the browser.ml.enabled setting to false. This should disable all AI features across the board, but community forums suggest this isn’t always enough to do the trick. For a scorched-earth approach, set the following parameters to false (or selectively keep only what you need):

  • ml.chat.enabled
  • ml.linkPreview.enabled
  • ml.pageAssist.enabled
  • ml.smartAssist.enabled
  • ml.enabled
  • ai.control.translations
  • tabs.groups.smart.enabled
  • urlbar.quicksuggest.mlEnabled

This will kill off chatbot integrations, AI-generated link descriptions, assistants and extensions, local translation of websites, tab grouping, and other AI-driven features.

How to disable AI features in Microsoft apps

Microsoft has managed to bake AI into almost every single one of its products, and turning it off is often no easy task — especially since the AI sometimes has a habit of resurrecting itself without your involvement.

How to disable AI features in Edge

Microsoft’s browser is packed with AI features, ranging from Copilot to automated search. To shut them down, follow the same logic as with Chrome: type edge://flags into the Edge address bar, hit Enter, then type “AI” or “Copilot” into the search box. From there, you can toggle off the unwanted AI features, such as:

  • Enable Compose (AI-writing) on the web
  • Edge Copilot Mode
  • Edge History AI

Another way to ditch Copilot is to enter edge://settings/appearance/copilotAndSidebar into the address bar. Here, you can customize the look of the Copilot sidebar and tweak personalization options for results and notifications. Don’t forget to peek into the Copilot section under App-specific settings — you’ll find some additional controls tucked away there.

How to disable Microsoft Copilot

Microsoft Copilot comes in two flavors: as a component of Windows (Microsoft Copilot), and as part of the Office suite (Microsoft 365 Copilot). Their functions are similar, but you’ll have to disable one or both depending on exactly what the Redmond engineers decided to shove onto your machine.

The simplest thing you can do is just uninstall the app entirely. Right-click the Copilot entry in the Start menu and select Uninstall. If that option isn’t there, head over to your installed apps list (Start → Settings → Apps) and uninstall Copilot from there.

In certain builds of Windows 11, Copilot is baked directly into the OS, so a simple uninstall might not work. In that case, you can toggle it off via the settings: Start → Settings → Personalization → Taskbar → turn off Copilot.

If you ever have a change of heart, you can always reinstall Copilot from the Microsoft Store.

It’s worth noting that many users have complained about Copilot automatically reinstalling itself, so you might want to do a weekly check for a couple of months to make sure it hasn’t staged a comeback. For those who are comfortable tinkering with the System Registry (and understand the consequences), you can follow this detailed guide to prevent Copilot’s silent resurrection by disabling the SilentInstalledAppsEnabled flag and adding/enabling the TurnOffWindowsCopilot parameter.

How to disable Microsoft Recall

The Microsoft Recall feature, first introduced in 2024, works by constantly taking screenshots of your computer screen and having a neural network analyze them. All that extracted information is dumped into a database, which you can then search using an AI assistant. We’ve previously written in detail about the massive security risks Microsoft Recall poses.

Under pressure from cybersecurity experts, Microsoft was forced to push the launch of this feature from 2024 to 2025, significantly beefing up the protection of the stored data. However, the core of Recall remains the same: your computer still remembers your every move by constantly snapping screenshots and OCR-ing the content. And while the feature is no longer enabled by default, it’s absolutely worth checking to make sure it hasn’t been activated on your machine.

To check, head to the settings: Start → Settings → Privacy & Security → Recall & snapshots. Ensure the Save snapshots toggle is turned off, and click Delete snapshots to wipe any previously collected data, just in case.

You can also check out our detailed guide on how to disable and completely remove Microsoft Recall.

How to disable AI in Notepad and Windows context actions

AI has seeped into every corner of Windows, even into File Explorer and Notepad. You might even trigger AI features just by accidentally highlighting text in an app — a feature Microsoft calls “AI Actions”. To shut this down, head to Start → Settings → Privacy & Security → Click to Do.

Notepad has received its own special Copilot treatment, so you’ll need to disable AI there separately. Open the Notepad settings, find the AI features section, and toggle Copilot off.

Finally, Microsoft has even managed to bake Copilot into Paint. Unfortunately, as of right now, there is no official way to disable the AI features within the Paint app itself.

How to disable AI in WhatsApp

In several regions, WhatsApp users have started seeing typical AI additions like suggested replies, AI message summaries, and a brand-new Chat with Meta AI button. While Meta claims the first two features process data locally on your device and don’t ship your chats off to their servers, verifying that is no small feat. Luckily, turning them off is straightforward.

To disable Suggested Replies, go to Settings → Chats → Suggestions & smart replies and toggle off Suggested replies. You can also kill off AI Sticker suggestions in that same menu. As for the AI message summaries, those are managed in a different location: Settings → Notifications → AI message summaries.

How to disable AI on Android

Given the sheer variety of manufacturers and Android flavors, there’s no one-size-fits-all instruction manual for every single phone. Today, we’ll focus on killing off Google’s AI services — but if you’re using a device from Samsung, Xiaomi, or others, don’t forget to check your specific manufacturer’s AI settings. Just a heads-up: fully scrubbing every trace of AI might be a tall order — if it’s even possible at all.

In Google Messages, the AI features are tucked away in the settings: tap your account picture, select Messages settings, then Gemini in Messages, and toggle the assistant off.

Broadly speaking, the Gemini chatbot is a standalone app that you can uninstall by heading to your phone’s settings and selecting Apps. However, given Google’s master plan to replace the long-standing Google Assistant with Gemini, uninstalling it might become difficult — or even impossible — down the road.

If you can’t completely uninstall Gemini, head into the app to kill its features manually. Tap your profile icon, select Gemini Apps activity, and then choose Turn off or Turn off and delete activity. Next, tap the profile icon again and go to the Connected Apps setting (it may be hiding under the Personal Intelligence setting). From here, you should disable all the apps where you don’t want Gemini poking its nose in.

How to disable AI in macOS and iOS

Apple’s platform-level AI features, collectively known as Apple Intelligence, are refreshingly straightforward to disable. In your settings — on desktops, smartphones, and tablets alike — simply look for the section labeled Apple Intelligence & Siri. By the way, depending on your region and the language you’ve selected for your OS and Siri, Apple Intelligence might not even be available to you yet.

Other posts to help you tune the AI tools on your devices:

  •  

2025 ISO and CSA STAR certificates are now available with one additional service and one new region

Amazon Web Services (AWS) successfully completed the annual recertification audit with no findings for ISO 9001:2015, 27001:2022, 27017:2015, 27018:2019, 27701:2019, 20000-1:2018, 22301:2019, and Cloud Security Alliance (CSA) STAR Cloud Controls Matrix (CCM) v4.0. The objective of the audit was to enable AWS to expand their ISO and CSA STAR certifications to include one new AWS Region and one new AWS service to the scope. The ISO standards cover areas including quality management, information security, cloud security, privacy protection, service management, and business continuity. The certifications demonstrate the commitment of AWS to maintaining robust security controls and protecting customer data across our services.

As part of this recertification audit, one new Region [Asia Pacific (Taipei)] and one new service (AWS Deadline Cloud) were added into the scope since the last certification issued November 25, 2025.

For a full list of AWS services that are certified under ISO and CSA Star, see the AWS
ISO and CSA STAR Certified page.
Customers can also access the certifications in the AWS Management Console through AWS Artifact.

If you have feedback about this post, submit comments in the Comments section below.

Chinmaee Parulekar

Chinmaee Parulekar

Chinmaee is a Compliance Program Manager at AWS. She has 6 years of experience in information security. Chinmaee holds a Master of Science degree in Management Information Systems and professional certifications such as CISA, HITRUST CCSF practitioner.

Atul Patil

Atulsing Patil
Atulsing is a Compliance Program Manager at AWS. He has 27 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, CDPSE, ISO 27001 Lead Auditor, HITRUST CSF, ISO 42001 Lead Auditor, Archer Certified Consultant, and AWS CCP.

  •  

Enhanced access denied error messages with policy ARNs

To help you troubleshoot access denied errors, we recently added the Amazon Resource Name (ARN) of the denying policy to access denied error messages. This builds on our 2021 enhancement that added the type of the policy denying the access to access denied error messages. The ARN of the denying policy is only provided in same-account and same-organization scenarios. This change is gradually rolling out across all AWS services in all AWS Regions.

What changed?

We added the policy ARN to access denied error messages for AWS Identity and Access Management (IAM) and AWS Organizations policies. Because of this change, you can now pinpoint the exact policy causing the denial. You don’t have to evaluate all the policies of the same type in your AWS environment to identify the culprit. The policy types covered in this update are service control policies (SCPs), resource control policies (RCPs), permissions boundaries policies, session policies, and identity-based policies.

For example, when a developer attempts to perform the ListRoles action in IAM and is denied because of an SCP:

Before:
An error occurred (AccessDenied) when calling the ListRoles operation: User: arn:aws:iam::123456789012:user/Matt is not authorized to perform: iam:ListRoles on resource: arn:aws:iam::123456789012:role/* with an explicit deny in a service control policy

Enhanced:
An error occurred (AccessDenied) when calling the ListRoles operation: User: arn:aws:iam::123456789012:user/Matt is not authorized to perform: iam:ListRoles on resource: arn:aws:iam::123456789012:role/* with an explicit deny in a service control policy: arn:aws:organizations::987654321098:policy/o-qv5af4abcd/service_control_policy/p-2kgnabcd

How this enhancement works

This enhancement is designed with three principles:

  • Limited scope – Same account and same organization only: Policy ARNs are only included when the request originates from either the same AWS account or the same organization as the policy. This limits the scope of the flow of information.
  • Additional context in the form of ARN only and not policy content: The additional context covers only the policy ARN, which is a resource identifier, not the policy document itself. It does not reveal the policy’s permissions or conditions that you would have to update to grant access. Users would still need appropriate permissions to read the policy content or take actions.
  • No change to authorization logic: This enhancement only affects the error message displayed, not the authorization decision-making process. The same policies deny or allow access as before, and we are not changing how the decision is made.

How this benefits you

This accelerates troubleshooting across your organization. Previously, when you received an access denied error from a policy, for example an SCP, you had to review all SCPs in your organization, determine which applied to the account, and evaluate each one—a process that could take time. Now, with the specific SCP ARN included in the error message, whoever has the necessary permission can review the identified SCP and more quickly resolve the issue. This precision reduces the investigative burden. Clear error messages with policy ARNs also improve communication between teams who need access and teams who troubleshoot issues by providing a common reference point, eliminating ambiguity and reducing back-and-forth communication. Lastly, when validating security controls, the policy ARN in access denied errors provides immediate confirmation of which policy is enforcing the restriction, enabling customers to quickly verify their policies are correctly denying access.

How you can use the new information

Let’s say you’re trying to describe your Amazon Relational Database Service (Amazon RDS) snapshots in the us-east-2 Region by calling this API:
aws rds describe-db-snapshots --region us-east-2

Unfortunately you get an access denied error. The error message shows:
An error occurred (AccessDenied) when calling the DescribeDBSnapshots operation: User: arn:aws:sts::123456789012:assumed-role/ReadOnly/ReadOnlySession is not authorized to perform: rds:DescribeDBSnapshots on resource: arn:aws:rds:us-east-2:123456789012:snapshot:* with an explicit deny in a service control policy: arn:aws:organizations::987654321098:policy/o-qv5af4abcd/service_control_policy/p-lvi9abcd

You can see the context to understand what happens:

  • It’s an explicit deny. This means there’s a policy that denies this action for a specific context
  • The deny comes from the SCP with this ARN: arn:aws:organizations::987654321098:policy/o-qv5af4abcd/service_control_policy/p-lvi9abcd

Here’s how you can troubleshoot this error:

  1. Ensure you have necessary permission to view the SCP. If you don’t, contact your administrator and provide the message that includes the policy ARN.
  2. If you have the necessary permission, go to the AWS Management Console for AWS Organizations to access the SCP.
  3. Check for a Deny statement for the action. In the preceding example, the action is rds:DescribeDBSnapshots.
  4. You can alter the statement to remove the Deny if it’s no longer applicable. For more information, see Update a service control policy (SCP).
  5. Re-try your operation. Repeat the troubleshooting process if you get other access denied errors due to different reasons or policies.

When will this change become available?

This update is gradually rolling out across all AWS services in all AWS Regions, beginning early 2026.

Need more assistance?

If you have any questions or issues, contact AWS Support or your Technical Account Manager (TAM).

Stella Hie

Stella Hie

Stella is a Senior Technical Product Manager for AWS Identity and Access Management (IAM). She specializes in improving developer experience and tooling while maintaining strong security standards. Her work focuses on making IAM straightforward to use and improving the troubleshooting experience for AWS customers. In her free time, she enjoys playing piano and bouldering.

  •  

Defending the gates: How a global coalition disrupted Tycoon 2FA, a major driver of initial access and large-scale online impersonation

One email was all it took. An employee clicked what looked like a routine signin request. Behind the scenes, attackers swiped credentials, slipped past security controls, impersonated a trusted user, and gained access to critical systems. In other cases, similar intrusions delayed paychecks, rerouted invoices, stole sensitive data, locked up entire networks, interrupted patient care, and strained already tight budgets at schools and critical services. 

Those attacks were powered by Tycoon 2FA. Today, Microsoft, Europol, and industry partners announced a coordinated action to disrupt the service responsible for tens of millions of fraudulent emails reaching over 500,000 organizations each month worldwide. 

Disrupting a global phishing operation 

Active since at least 2023, Tycoon 2FA enabled thousands of cybercriminals to impersonate real users and gain unauthorized access to email and online service accounts, including Microsoft 365, Outlook, and Gmail. Unlike traditional phishing kits, Tycoon 2FA was designed to defeat additional security protections, including multifactor authentication, allowing cybercriminals to log in as legitimate users without triggering alerts, even on protected accounts. 

Acting under a court order from the U.S. District Court for the Southern District of New York, and for the first time in coordination with Europol’s Cyber Intelligence Extension Programme (CIEP), Microsoft seized 330 active domains that powered Tycoon 2FA’s core infrastructure, including control panels and fraudulent login pages. The CIEP framework brought public and privatesector partners together to move from simply sharing intelligence to coordinated, crossborder action, accelerating disruption and limiting further harm. 

Taking this infrastructure offline cuts off a major pipeline for account takeovers and helps protect people and organizations from followon attacks such as data theft, ransomware, business email compromise, and financial fraud. 

The scale and realworld impact of Tycoon 2FA 

By mid2025, Tycoon 2FA accounted for approximately 62 percent of all phishing attempts Microsoft blocked, including more than 30 million emails in a single month. That placed Tycoon 2FA among the largest phishing operations globally.  

Despite extensive defenses, the service is linked to an estimated 96,000 distinct phishing victims worldwide since 2023, including more than 55,000 Microsoft customers.  

Healthcare and education organizations were hit hardest. More than 100 members of HealthISAC, a global threat-sharing group for the health sector and a co-plaintiff in this case, were successfully phished. In New York alone, at least two hospitals, six municipal schools, and three universities faced attempted or successful compromise through Tycoon 2FA. These incidents had tangible consequences: disrupted operations, diverted resources, and delayed patient care.  

Why Tycoon 2FA was so dangerous 

Tycoon 2FA combined convincing phishing templates, realistic landing pages, and realtime capture of credentials and authentication codes into an easytouse package that scaled quickly. By lowering the technical barrier to entry, it allowed criminals with limited expertise to run sophisticated impersonation campaigns. 

With each successful phishing victim, attackers could operate with the same level of trust as legitimate users moving laterally across systems, accessing sensitive data, and abusing signon connections without raising alarms. Research from Microsoft Threat Intelligence provides more details on how Tycoon 2FA operated. 

Dark‑themed admin dashboard showing security and login activity. At the top are summary cards for Total Visits (5), Valid (4), Invalid (2), and SSO (0). The center includes a donut chart comparing valid, invalid, and SSO logins, a bar chart of login websites with Microsoft highlighted, and a world map labeled “Visitors by Country.” Below, a table lists valid accounts with columns for email, website, browser, IP, country, 2FA status, and date, with action buttons such as “Copy Zip Pass” and “Download.”
The Tycoon 2FA customer dashboard.

This shift reflects a broader trend in cybercrime: identity, not infrastructure, has become the primary target. A single compromised account can now unlock banking systems, healthcare portals, workplace applications, and social media accounts. 

Inside the impersonation economy

Tycoon 2FA operated like a business within the broader impersonationforhire ecosystem. The primary developer, Saad Fridi, who is believed to be based in Pakistan, worked alongside partners responsible for marketing, payments, and technical support. 

Cybercriminals typically used Tycoon 2FA alongside other illicit services. While Tycoon 2FA captured credentials and session tokens, other services handled mass email delivery, malware distribution, hosting, and access monetization. For example, RedVDS, disrupted by Microsoft in January 2026, provided inexpensive virtual computers, which cybercriminals paired with Tycoon 2FA to deliver phishing campaigns. Together, these different services created an interconnected ecosystem for identitybased attacks. Disrupting one component can have cascading effects across the cybercrime economy. 

Sustained pressure reshapes the market 

Over the past 18 months, Microsoft’s Digital Crimes Unit has targeted multiple services that enable impersonation and initial access, including extensive disruption operations of Lumma StealerRaccoonO365Fake ONNX (aka “Caffeine”), and RedVDS. 

When widely used tools are disrupted, attackers are forced to adapt, often shifting to alternatives like Tycoon 2FA. This substitution pattern shows how sustained pressure prevents any single service from remaining dominant while steadily raising the cost and risk of cybercrime. 

These efforts have led to arrests in Egypt and Nigeria, complete service shutdowns, infrastructure loss, and reputational damage for operators beyond lawenforcement reach. RedVDS alone lost more than 95 percent of its infrastructure since January 2026, significantly degrading its ability to support mass impersonation campaigns and other online scams. 

As pressure increased, many operators tightened access controls, retreated into closed channels, or shut down entirely to avoid legal action. In Tycoon 2FA’s case, Microsoft could not purchase access to the service; the operator rejected attempts by our investigators, requiring a trusted intermediary. In fact, Tycoon 2FA’s operator and the nowarrested developer of RaccoonO365 communicated with one another, highlighting the ecosystem’s interdependence and how disruptions in one area influence activity elsewhere. 

Screenshot of a dark‑mode chat conversation interface. Multiple message bubbles discuss “2FA/MFA” services, with usernames such as “Raccoon0365,” “ItsPump,” and others visible. Messages reference choosing or not choosing a provider, friendship between groups, and competition between services. Timestamps appear next to messages, and emoji reactions are included.
Correspondence suggesting interactions between the operators of RaccoonO365 and Tycoon 2FA.

Global threats require global action 

Cybercrime operates across borders, and effective response must do the same. Disrupting Tycoon 2FA spanned multiple jurisdictions, underscoring why sustained, coordinated pressure is essential, especially as cybercrime becomes more scalable through automation and AI. 

Microsoft Threat Intelligence, joining many security researchers, identified Tycoon 2FA as one of the most significant threats to identity-based attacks. Microsoft’s Digital Crimes Unit consulted with Europol, which also tracked the actor based on intelligence supplied by TrendAI. Through the CIEP, Europol convened partners to take action. Microsoft worked with industry partners to pursue a coordinated infrastructure disruption, while law enforcement authorities in Latvia, Lithuania, Portugal, Poland, Spain, and the United Kingdom conducted seizures of infrastructure and carried out other operational measures linked to Tycoon 2FA. 

Industry partners, including ProofpointIntel 471, and eSentire, expanded visibility through telemetry, threat intelligence, and criminalforum insight. Cloudflare assisted by taking down infrastructure outside U.S. jurisdiction, while HealthISAC quantified impacts on healthcare organizations. SpyCloud contributed key victimology data, Resecurity facilitated access to Tycoon 2FA, and Coinbase helped trace the movement of stolen funds. Finally, the Shadowserver Foundation supported notifications to more than 200 computer emergency response teams worldwide, helping limit further harm. 

No single organization could have assembled this full picture alone.

Splash page appearing on seized domains.

Sustaining pressure, together 

Stopping identitybased cybercrime requires action across individuals, organizations, and governments. Multifactor authentication, scrutiny of unexpected messages, strong session controls, and coordinated threatsharing all reduce risk. Early enforcement matters tooit prevents small intrusions from escalating into systemic harm. Microsoft will continue applying the lessons learned from Tycoon 2FA and prior disruptions to fragment the impersonation economy, limit scale, and make cybercrime riskier and less profitable. 

The post Defending the gates: How a global coalition disrupted Tycoon 2FA, a major driver of initial access and large-scale online impersonation appeared first on Microsoft On the Issues.

  •  

2025 FINMA ISAE 3000 Type II attestation report available with 183 services in scope

Amazon Web Services (AWS) is pleased to announce the issuance of the Swiss Financial Market Supervisory Authority (FINMA) Type II attestation report with 183 services in scope.

The Swiss Financial Market Supervisory Authority (FINMA) has published several requirements and guidelines about engaging with outsourced services for the regulated financial services customers in Switzerland.

An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and operating effectively to support of adherence with FINMA requirements.

The latest report covers the 12-month period from October 1, 2024 to September 30, 2025 for the following circulars:

  • 2018/03 Outsourcing – banks, insurance companies and selected financial institutions under FinIA
  • 2023/01 Operational risks and resilience – banks
  • Business Continuity Management (BCM) minimum standards proposed by the Swiss Insurance Association.

AWS has added the following five services to the current FINMA scope:

Customers can find the FINMA ISAE 3000 report on AWS Artifact. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.
Security and compliance is a shared responsibility between AWS and the customer. When customers move their computer systems and data to the cloud, security responsibilities are shared between the customer and the cloud service provider. For more information, see the AWS Shared Security Responsibility Model.

To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

If you have feedback about this post, submit comments in the Comments section below

Tariro Dongo Tariro Dongo
Tari is a Security Assurance Program Manager at AWS, based in London. Tari is responsible for third-party and customer audits, attestations, certifications, and assessments across EMEA. Previously, Tari worked in security assurance and technology risk in the big four and financial services industry over the last 15 years.
  •  

2025 PiTuKri ISAE 3000 Type II attestation report available with 183 services in scope

Amazon Web Services (AWS) is pleased to announce the issuance of the Criteria to Assess the Information Security of Cloud Services (PiTuKri) Type II attestation report with 183 services in scope.

The Finnish Transport and Communications Agency (Traficom) Cyber Security Centre published PiTuKri, which consists of 52 criteria that provide guidance across 11 domains for assessing the security of cloud service providers.

An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and operating effectively to demonstrate adherence with PiTuKri requirements. This attestation demonstrates the AWS commitment to meet security expectations for cloud service providers set by Traficom.

The latest report covers a 12-month period from October 1, 2024 to September 30, 2025. AWS has added the following five services to the current PiTuKri scope:

Customers can find the PiTuKri ISAE 3000 report on AWS Artifact. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

Security and compliance is a shared responsibility between AWS and the customer. When customers move their computer systems and data to the cloud, security responsibilities are shared between the customer and the cloud service provider. For more information, see the AWS Shared Security Responsibility Model.

To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

If you have feedback about this post, submit comments in the Comments section below

Tariro Dongo Tariro Dongo
Tari is a Security Assurance Program Manager at AWS, based in London. Tari is responsible for third-party and customer audits, attestations, certifications, and assessments across EMEA. Previously, Tari worked in security assurance and technology risk in the big four and financial services industry over the last 15 years.
  •  

Understanding IAM for Managed AWS MCP Servers

As AI agents become part of your development workflows on Amazon Web Services (AWS), you want them to work with your existing AWS Identity and Access Management (IAM) permissions, not force you to build a separate permissions model. At the same time, you need the flexibility to apply different governance controls when an AI agent makes an API call compared to when a developer does it directly. In this post, we show you how to use new standardized IAM context keys for AWS-managed remote Model Context Protocol (MCP) servers, a simplified authorization model that works like the AWS CLI and SDKs you already use, and upcoming VPC endpoint support for network perimeter controls.

Overview

At re:Invent 2025, we launched four AWS-managed remote MCP servers (AWS, EKS, ECS, and SageMaker) in preview. AWS hosts and manages remote MCP servers, removing the need for local installation and maintenance while providing automatic updates, resiliency, scalability, and complete audit logging through AWS CloudTrail. For example, with the AWS MCP Server you can access AWS documentation and execute calls to over 15,000 AWS APIs, helping AI agents perform multi-step tasks like setting up VPCs or configuring Amazon CloudWatch alarms.

We heard from customers that, as AI agents become more integrated into dev workflows, you want these workflows to work with existing AWS permissions without having to reconfigure IAM policies or create separate permissions models for AI. At the same time, you want the flexibility to apply different governance controls for AI actions compared to direct human actions. We recently introduced two standardized IAM context keys (aws:ViaAWSMCPService and aws:CalledViaAWSMCP) that give you this control. These context keys work consistently across all AWS-managed remote MCP servers, so you can implement defense-in-depth security, maintain detailed audit trails, and meet compliance requirements by differentiating between calls using AI solutions and human-initiated actions. In addition, we heard from customers the need to simplify the authorization model. Starting soon, you will no longer need to separate MCP-specific IAM actions (such asaws-mcp:InvokeMCP) to interact with AWS-managed MCP servers. This aligns with how AWS Command Line Interface (AWS CLI) and AWS SDKs work today, reducing configuration overhead, while your existing IAM policies continue to control what actions can be performed. Looking ahead, we’re adding VPC endpoint support for AWS-managed MCP servers so you can connect directly from your VPC, providing enhanced security through two-stage authorization and network perimeter controls for customers who need to enforce identity and network perimeters.

Using IAM to differentiate between human-driven and AI-driven actions

To give you fine-grained control over AI solutions using MCP servers, we’ve introduced two standardized IAM context keys. These keys work consistently across all AWS-managed MCP servers:

  • aws:ViaAWSMCPService (boolean): Set to true when the request comes through an AWS-managed MCP server. Use this to allow or deny all MCP-initiated actions.
  • aws:CalledViaAWSMCP (string, single valued): Contains the service principal name of the MCP server (for example, aws-mcp.amazonaws.com, eks-mcp.amazonaws.com, and ecs-mcp.amazonaws.com). Use this to allow or deny actions from specific MCP servers. This context key value will include more MCP servers when new MCP servers are available, allowing you to configure fined grained access to your AWS resources through IAM and SCP policies.

For organizations that want to completely disable MCP server access across their organization or specific organizational units, you can use a service control policy (SCP) to deny all or some actions when accessed through MCP servers:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllActionsViaMCP",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:ViaAWSMCPService": "true"
        }
      }
    }
  ]
}

In another example, you can allow AI agents using AWS MCP Server to read Amazon Simple Storage Service (Amazon S3) buckets but deny delete operations. The AWS MCP Server provides the aws___call_aws tool, which can execute any AWS API operation, including Amazon S3 operations:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOperations",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyDeleteWhenAccessedViaMCP",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteBucket"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:ViaAWSMCPService": "true"
        }
      }
    }
  ]
}

You can also restrict access to specific AWS-managed MCP servers. For example, allow EKS operations only when called through the EKS MCP server, not through the AWS MCP server:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEKSOperationsViaEKSMCP",
      "Effect": "Allow",
      "Action": "eks:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:CalledViaAWSMCP": "eks-mcp.amazonaws.com"
        }
      }
    },
    {
      "Sid": "DenyEKSOperationsViaOtherMCP",
      "Effect": "Deny",
      "Action": "eks:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:CalledViaAWSMCP": "eks-mcp.amazonaws.com"
        }
      }
    }
  ]
}

Understanding the changes for public endpoint authorization

Based on feedback, we’re simplifying the authorization model to work like the AWS CLI and SDKs you already use. Moving forward, the MCP server adds the standardized IAM context keys (aws:ViaAWSMCPService and aws:CalledViaAWSMCP) to your request and forwards it to the downstream AWS service. The MCP server will still authenticate your request using SigV4 as before. Now, the downstream service performs the authorization check using your existing IAM policies, which can reference these context keys for fine-grained control. This means your AI agents work with your existing AWS credentials and service-level permissions, eliminating the need for separate MCP-specific IAM actions and reducing configuration overhead. The following diagram illustrates how this simplified authorization flow works:

Figure 1: Authorization flow for managed MCP servers.

Figure 1: Authorization flow for managed MCP servers.

Using IAM with MCP servers and VPC endpoints

We also heard from customers in regulated industries who need additional network-level controls for AI agent access. Customers in industries like financial services and healthcare require private network communication to meet compliance mandates. To meet these requirements, AWS will also add VPC endpoint support for AWS-managed MCP servers in the future. You can use VPC endpoints to keep all AI agent traffic within your private network, eliminating exposure through the public internet. When you configure a VPC endpoint, the MCP server performs an authorization check at the VPC endpoint level before forwarding requests to downstream AWS services. This creates a defense-in-depth approach where you control access at both the network perimeter (VPC endpoint) and the service level (IAM policies). You can combine VPC endpoints with the aws:ViaAWSMCPService and aws:CalledViaAWSMCP context keys to implement layered security controls that meet your organization’s specific governance and compliance requirements. Additional details on context keys and example patterns will be available when support for VPC endpoints is launched.

Things to consider

When implementing IAM authorization for MCP servers, you need to make decisions about deployment patterns, policy design, and operational practices. Here are key considerations to help you choose the right approach for your organization.

  • Designing IAM policies: Only give access that is needed, and refine policies and remove unused access over time. Use context keys to differentiate calls using AI solutions from direct developer actions.
  • Security and compliance: VPC endpoints help meet requirements for private network communication in regulated industries.
  • Getting started: Start with the deployment pattern that matches your current needs. Begin with restrictive IAM policies and relax them as you understand your AI agents’ requirements. Monitor CloudTrail logs to see what actions your AI agents perform and use the data to refine your policies over time.

Conclusion

You now have the control to govern AI agent access to your AWS resources through AWS-managed MCP Server using the same IAM policies and tools you already trust. The standardized IAM context keys (aws:ViaAWSMCPService and aws:CalledViaAWSMCP) are available across all AWS-managed MCP servers, giving you fine-grained control to differentiate calls using AI solutions from direct developer actions at the service level. In upcoming releases, AWS managed MCP servers will work without separate IAM actions over public endpoints and simplify your IAM policy management. We will also provide support for VPC endpoints with enhanced security through two-stage authorization and network perimeter controls for customers who need additional access restrictions. See the documentation for your specific AWS-managed MCP server to confirm whether it supports the new public endpoint authorization model and VPC endpoints. Whether you’re building AI coding assistants or agentic applications, start implementing these controls today to secure your AI workflows while maintaining the flexibility to define access rules that match your organization’s security posture.

Riggs Goodman III Riggs Goodman III
Riggs is a Principal Partner Solution Architect at AWS. His current focus is on AI security and networking, providing technical guidance, architecture patterns, and leadership for customers and partners to build AI workloads on AWS. Internally, Riggs focuses on driving overall technical strategy and innovation across AWS service teams to address customer and partner challenges.
Shreya Jain

Shreya Jain

Shreya is a Senior Technical Product Manager in AWS Identity. She is energized by bringing clarity and simplicity to complex ideas. When she’s not applying her creative energy at work, you’ll find her at Pilates, dancing, or discovering her next favorite coffee shop.

Praneeta Prakash Praneeta Prakash
Praneeta is a Senior Product Manager at AWS Developer Tools, where she drives innovation at the intersection of cloud infrastructure and developer experience. She works on strategic initiatives that shape how developers interact with cloud infrastructure, particularly in the evolving landscape of AI-native development. Her work centers on making AWS more accessible and intuitive for developers of all skill levels, from frontend engineers building their first cloud application to experienced teams scaling production systems.
Brian Ruf Khaled Sinno
Khaled is a Principal Engineer at Amazon Web Services. His current focus is on Identity and Access Management in AWS and more generally on providing identity and security controls for customers in the cloud. In the past, he has worked on availability and security within AWS RDS (i.e. databases) while also contributing more broadly to the security space of database and search services. Prior to AWS, Khaled led large engineering teams in the FinTech industry, working on distributed systems in finance and trading platforms.
  •  

CVE-2026-3102: macOS ExifTool image-processing vulnerability | Kaspersky official blog

Can a computer be infected with malware simply by processing a photo — particularly if that computer is a Mac, which many still believe (wrongly) to be inherently resistant to malware? As it turns out, the answer is yes — if you’re using a vulnerable version of ExifTool or one of the many apps built based on it. ExifTool is a ubiquitous open-source solution for reading, writing, and editing image metadata. It’s the go-to tool for photographers and digital archivists, and is widely used in data analytics, digital forensics, and investigative journalism.

Our GReAT experts discovered a critical vulnerability — tracked as CVE-2026-3102 — which is triggered during the processing of malicious image files containing embedded shell commands within their metadata. When a vulnerable version of ExifTool on macOS processes such a file, the command is executed. This allows a threat actor to perform unauthorized actions in the system, such as downloading and executing a payload from a remote server. In this post, we break down how this exploit works, provide actionable defense recommendations, and explain how to verify if your system is vulnerable.

What is ExifTool?

ExifTool is a free, open-source application addressing a niche but critical requirement: it extracts metadata from files, and enables the processing of both that data and the files themselves. Metadata is the information embedded within most modern file formats that describes or supplements the main content of a file. For instance, in a music track, metadata includes the artist’s name, song title, genre, release year, album cover art, and so on. For photographs, metadata typically consists of the date and time of a shot, GPS coordinates, ISO and shutter speed settings, and the camera make and model. Even office documents store metadata, such as the author’s name, total editing time, and the original creation date.

ExifTool is the industry leader in terms of the sheer volume of supported file formats, as well as the depth, accuracy, and versatility of its processing capabilities. Common use cases include:

  • Adjusting dates if they’re incorrectly recorded in the source files
  • Moving metadata between different file formats (from JPG to PNG and so on)
  • Pulling preview thumbnails from professional RAW formats (such as 3FR, ARW, or CR3)
  • Retrieving data from niche formats, including FLIR thermal imagery, LYTRO light-field photos, and DICOM medical imaging
  • Renaming photo/video (etc.) files based on the time of actual shooting, and synchronizing the file creation time and date accordingly
  • Embedding GPS coordinates into a file by syncing it with a separately stored GPS track log, or adding the name of the nearest populated area

The list goes on and on. ExifTool is available both as a standalone command-line application and an open-source library, meaning its code often runs under the hood of powerful, multi-purpose tools; examples include photo organization systems like Exif Photoworker and MetaScope, or image processing automation tools like ImageIngester. In large digital libraries, publishing houses, and image analytics firms, ExifTool is frequently used in automated mode, triggered by internal enterprise applications and custom scripts.

How CVE-2026-3102 works

To exploit this vulnerability, an attacker must craft an image file in a certain way. While the image itself can be anything, the exploit lies in the metadata — specifically the DateTimeOriginal field (date and time of creation), which must be recorded in an invalid format. In addition to the date and time, this field must contain malicious shell commands. Due to the specific way ExifTool handles data on macOS, these commands will execute only if two conditions are met:

  • The application or library is running on macOS
  • The -n (or –printConv) flag is enabled. This mode outputs machine-readable data without additional processing, as is. For example, in -n mode, camera orientation data is output simply, inexplicably, as “six”, whereas with additional processing, it becomes the more human-readable “Rotated 90 CW”. This “human-readability” prevents the vulnerability from being exploited

A rare but by no means fantastical scenario for a targeted attack would look like this: a forensics laboratory, a media editorial office, or a large organization that processes legal or medical documentation receives a digital document of interest. This can be a sensational photo or a legal claim — the bait depends on the victim’s line of work. All files entering the company undergo sorting and cataloging via a digital asset management (DAM) system. In large companies, this may be automated; individuals and small firms run the required software manually. In either case, the ExifTool library must be used under the hood of this software. When processing the date of the malicious photo, the computer where the processing occurs is infected with a Trojan or an infostealer, which is subsequently capable of stealing all valuable data stored on the attacked device. Meanwhile, the victim could easily notice nothing at all, as the attack leverages the image metadata while the picture itself may be harmless, entirely appropriate, and useful.

How to protect against the ExifTool vulnerability

GReAT researchers reported the vulnerability to the author of ExifTool, who promptly released version 13.50, which is not susceptible to CVE-2026-3102. Versions 13.49 and earlier must be updated to remediate the flaw.

It’s critical to ensure that all photo processing workflows are using the updated version. You should verify that all asset management platforms, photo organization apps, and any bulk image processing scripts running on Macs are calling ExifTool version 13.50 or later, and don’t contain an embedded older copy of the ExifTool library.

Naturally, ExifTool — like any software — may contain additional vulnerabilities of this class. To harden your defenses, we also recommend the following:

  • Isolate the processing of untrusted files. Process images from questionable sources on a dedicated machine or within a virtual environment, strictly limiting its access to other computers, data storage, and network resources.
  • Continuously track vulnerabilities along the software supply chain. Organizations that rely on open-source components in their workflows can use Open Source Software Threats Data Feed for tracking.

Finally, if you work with freelancers or self-employed contractors (or simply allow BYOD), only allow them to access your network if they have a comprehensive macOS security solution installed.

Still think macOS is safe? Then read about these Mac threats:

  •  

Why Service Providers Must Become Secure AI Factories

The Pivot to Large-Scale Intelligence

For decades, Telecommunications Service Providers have been the central nervous system of the global economy, tasked with a singular, critical mission: connecting people.

The industry spent vast amounts of capital building networks that moved voice, then text and finally high-speed mobile data. We succeeded. According to GSMA's most recent report, there are 5.8 billion unique subscriptions. The world is connected.

But the mission is changing fast. We are no longer just moving data; we are now expected to host intelligence.

Today’s enterprises are drowning in data and desperate for AI-led capabilities to analyze and process the information. They are struggling with the immense capital costs, the scarcity of GPUs, and complex data sovereignty regulations that make public cloud options difficult for sensitive workloads.

We are no longer living in the communications age, or the internet age, or the social network era, not even in the generative AI era. We are entering the Agentic Era. In this new era, data is the raw resource, and AI agents and models are the machinery that refines it into value. The infrastructure required to do this – from massive data ingestion to complex training and high-volume real-time inference – is called the "AI Factory.”

And these AI factories are not being designed for human-speed operations, but rather for machine-speed operations.

This creates a generational opportunity for telecommunications service providers (SP). By building new (or transforming existing) data centers and edge locations into AI factories, SPs can offer hosted AI services that are high-performance, low-latency and compliant with regional requirements.

However, building an AI factory isn't just about racking GPUs. It is about realizing that an AI infrastructure presents a fundamentally new threat landscape that legacy security cannot handle. If the SP’s AI factory is compromised (if models are poisoned, identities hijacked, training data exfiltrated) the damage to reputation and national infrastructure is incalculable.

To capture the AI opportunity, service providers need more than computing power; they need a blueprint for a secure AI architecture. At Palo Alto Networks, we view the security of the AI factory as a three-tiered layer cake, requiring holistic, integrated protection from the physical infrastructure up to the AI agents themselves.

The AI Threat Model Is a Structural Shift

For service providers building AI Factories, the challenge is not simply adding another workload to the data center. AI changes the risk equation entirely. It introduces new traffic patterns, new identities and new forms of autonomy that traditional network and core security architectures were never designed to govern.

  • Data Gravity Becomes Attack Surface: AI training and inference environments ingest massive volumes of data from distributed enterprise customers, partners and edge environments. This scale creates a new exposure layer. Malicious payloads, embedded model manipulation, and command-and-control traffic can hide within high-throughput AI data flows. Inspection models built for deterministic traffic patterns struggle when confronted with dynamic, AI-driven pipelines.
  • Non-Human Identities at Scale: An AI Factory is more than just infrastructure; it will be populated by autonomous agents. These agents retrieve data, call APIs, invoke tools and trigger workflows across networks and cloud environments. They require elevated privileges to function. For service providers, this means managing not just subscriber identities, but fleets of machine identities operating with delegated authority.
  • Agentic and Adversarial Threats: Attackers are also operationalizing AI. They probe for weaknesses faster, automate exploitation and increasingly target the AI systems themselves. Prompt injection can redirect an agent’s mission. Data poisoning can subtly degrade model integrity. Rogue agents can be manipulated to access external tools or escalate privileges. These are not traditional perimeter attacks; they are attacks on reasoning, behavior and autonomy.

For service providers offering AI-as-a-Service, the implication is clear: Securing the AI Factory requires more than network defense. It requires real-time governance of models, agents and data flows, ensuring that autonomous systems operate within defined policy boundaries while maintaining performance and scale.

Next-gen platforms enable transformation.
The security of the AI factory required holistic, integrated protection from the physical infrastructure up to the AI agents themselves.

The Foundation — Securing the High-Performance Infrastructure

The base of our cybersecurity stack is the physical and virtual infrastructure of the AI factory itself. This is a high-stakes environment. In a multitenant SP data center, you might have a financial institution fine-tuning a fraud detection model on one rack, and a government agency running inference on satellite imagery on the next. The barriers between these tenants must be absolute.

Foundational cybersecurity has two critical components: perimeter defense and internal segmentation.

The ML-Powered Perimeter

The front door of the AI factory must handle unprecedented throughput while performing deep inspection. Traditional firewalls, relying on static signatures, become bottlenecks and fail to catch novel threats hidden in massive data streams.

Palo Alto Networks addresses this with our flagship ML-Led Next-Generation Firewalls (NGFW). We have embedded machine learning directly into the core of the firewall. Instead of waiting for a patient zero to be identified and a signature created, our NGFWs analyze traffic patterns in real-time to identify and block unknown threats instantly. For an SP, this means you can provide the massive bandwidth required for AI data ingestion without compromising on security inspection at the edge.

Zero Trust Segmentation Inside the Factory

The perimeter is just the start. Once inside the data center, the biggest risk is the lateral movement threats and malware. If an attacker compromises a low-security tenant or a peripheral IoT device, they must not be able to jump to the sensitive GPU clusters or the model storage arrays.

In an AI factory, workloads are highly dynamic and virtualized. We provide robust segmentation across both hardware and software environments. We can enforce granular policies between virtual instances, containers and different stages of the AI pipeline (e.g., isolating training environments from inference operations). This allows a breach in one segment to be contained instantly, protecting the integrity of the entire factory.

The Engine – Securing AI Agents, Apps and Identities

The middle layer of the security stack is where the actual "work" of AI happens – the models, the LLMs, the agents. This is the newest frontier of cybersecurity and where traditional tools are most deficient.

This layer faces two distinct challenges: Protecting the integrity of the AI interaction and managing the identities of the nonhuman actors.

Securing AI Apps and Agents

As enterprises evolve from standalone LLMs to agentic AI systems that reason, call tools, access data, and take action across workflows, the challenge is no longer just what a model says; it is what an AI agent does.

How do you validate that an LLM powering your AI factory does not expose sensitive information, and that autonomous agents cannot be manipulated through jailbreak prompts, tool injection or malicious instructions? How do you prevent an AI agent from accessing unauthorized systems, escalating privileges, or executing unintended actions?

This is the role of Prisma® AIRS™ – our security and governance platform for AI agents, apps, models and data. Prisma AIRS operates directly in the execution path of AI applications and autonomous agents. It enforces policy in real time, validates agent behavior, and blocks prompt injection, model manipulation and agent hijacking before they can impact the business.

Beyond filtering outputs, Prisma AIRS governs agent communications, tool access and data flows to prevent credential leakage, mission drift and unauthorized actions. For service providers delivering AI-as-a-Service, or enterprises deploying AI agents internally, Prisma AIRS enables integrity, compliance and continuous control as intelligent systems move from experimentation into mission-critical operations.

Built in alignment with emerging standards like the OWASP Agentic Top 10 Survival Guide, Prisma AIRS operationalizes best practices to defend against real-world agentic threats.

Governing Nonhuman Identity

Perhaps the most profound shift in the AI factory is who or what is doing the work. We are rapidly moving toward ecosystems of autonomous AI Agents. These agents need to authenticate to databases, authorize API calls to other services, and access privileged information just like a human employee.

If an attacker steals the credentials of a high-privilege AI agent, they own the factory.

This is why the Palo Alto Networks acquisition of CyberArk, the global leader in Identity Security, is so strategic for the AI era. CyberArk specializes in protecting privileged access, and crucially managing nonhuman identities. By integrating CyberArk’s capabilities, we can ensure that every AI agent operating within the SP’s factory is robustly authenticated, authorized for minimum necessary access, and its activities are monitored. We are securing the new digital workforce.

The Overwatch – Holistic, AI-Driven Threat Management

The top layer of the stack is about visibility and speed. An AI factory generates a deafening amount of telemetry data from networks, endpoints, clouds and identity systems. No human security operations center (SOC) can sift through this noise manually to find a sophisticated attack.

To fight AI-driven threats, you need AI-driven defense.

This is the role of Cortex®, our flagship platform for holistic threat management. Cortex is designed to ingest billions of data points from across the entire Palo Alto Networks product portfolio and hundreds of types of third-party equipment, normalizing it into a single source of truth.

Cortex applies advanced AI and machine learning to this vast data lake to detect anomalies that signal a complex attack spanning different threat vectors. It might correlate an unusual login event from an AI agent (detected by the identity layer) with a subtle change in outbound traffic patterns at the firewall (layer 1), recognizing it as data exfiltration in progress.

For a Service Provider, Cortex provides the "single pane of glass" view over their entire AI factory operations, allowing them to detect, investigate and automatically respond to threats at machine speed, vastly reducing Mean Time to Respond (MTTR).

Building the Trust Foundation for the Agentic Era

The transition to becoming an AI factory is a necessary evolution for Service Providers seeking growth in the coming decade. Your ability to offer localized, sovereign, high-performance AI services will differentiate you from those who large-scale and cement your role as an indispensable partner to enterprises and governments.

But this opportunity is inextricably linked to trust. Your customers will not move their most sensitive data and IP into your AI factory unless they are certain it is secure against modern threats.

Security cannot be an afterthought bolted onto an AI infrastructure. It must be woven into the fabric of the factory, from the silicon to the software agents. By adopting a layered approach (securing the high-performance infrastructure with ML-led NGFWs, protecting models and identities with Prisma AIRS and CyberArk, while managing the entire landscape with Cortex) Service Providers can build the trusted foundations the AI era demands.

This week we’ll be at Mobile World Congress talking about our security platform for AI Factories, along with five solutions and ecosystem partners. Come see us at in Hall 4, Stand #4D55.

The post Why Service Providers Must Become Secure AI Factories appeared first on Palo Alto Networks Blog.

  •  

AWS successfully completed its first surveillance audit for ISO 42001:2023 with no findings

In November 2024, Amazon Web Services (AWS) was the first major cloud service provider to announce the ISO/IEC 42001 accredited certification for AI services, covering: Amazon Bedrock, Amazon Q Business, Amazon Textract, and Amazon Transcribe.

In November 2025, AWS successfully completed its first surveillance audit for ISO 42001:2023, Artificial Intelligence Management System with no findings.

This demonstrates the continual commitment of AWS to responsible AI practices. With this independent validation, our customers can gain further assurances around the AWS commitment to responsible AI and their ability to build and operate AI applications responsibly using AWS services.

For a full list of AWS services that are certified under ISO and CSA STAR, see the AWS ISO and CSA STAR Certified page. Customers can also access the certifications in the AWS Management Console through AWS Artifact.

If you have feedback about this post, submit comments in the Comments section below.
 

Atul Patil

Atulsing Patil
Atulsing is a Compliance Program Manager at AWS. He has 27 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, CDPSE, ISO 27001 Lead Auditor, HITRUST CSF, Archer Certified Consultant, and AWS CCP.

  •  

Inside AWS Security Agent: A multi-agent architecture for automated penetration testing

AI agents have traditionally faced three core limitations: they can’t retain learned information or operate autonomously beyond short periods, and they require constant supervision. AWS addresses these limitations with frontier agents—a new category of AI that performs complex reasoning, multi-step planning, and autonomous execution for hours or days. Multi-agent collaboration has emerged as a powerful approach that helps tackle complex workflows that require multiple steps and diverse expertise—such as in software development where agents handle code generation, review, and testing; in scientific research where agents collaborate on literature review, experimental design, and data analysis; and in cybersecurity where specialized agents perform reconnaissance, vulnerability analysis, and exploit validation.

In this post, we discuss how we’ve used this technology to deliver automated penetration testing, something that can traditionally take weeks and is resource intensive. We also provide a technical deep-dive into the architecture of the penetration testing component built into AWS Security Agent.

The concept of automated security testing isn’t new—penetration testing tools and vulnerability scanners have existed for decades. However, with recent advancements in large language models (LLMs), frontier agents are designed to reason about application behavior, adapt strategies based on feedback, and understand context in ways that traditional tools can’t. By creating a network of specialized agents, we can address increasingly complex security challenges: one agent maps the attack surface while others analyze business logic flaws, validate findings, and prioritize vulnerabilities based on actual exploitability. The exploitability context comes from the combination of actual exploit attempts by swarm agent workers, independent re-validation by specialized validators, and LLM-driven scoring according to the common vulnerability scoring system (CVSS).

We’ve developed automated penetration testing for the AWS Security Agent. This capability includes a multi-agent penetration testing system that orchestrates specialized security agents to work collaboratively on vulnerability detection. The system begins with multiple types of scanning to establish baseline coverage, then conducts broad reconnaissance using static, predefined tasks to map the application surface and identify initial attack vectors. Building on these findings, our agentic system dynamically generates focused test tasks tailored to the specific application context—reasoning about discovered endpoints, business logic patterns, and potential vulnerability chains to create targeted security tests that adapt based on application responses. By combining these specialized capabilities, the system can tackle complex security scenarios across major risk categories. Beyond single-vulnerability detection, the system performs complex chained attacks—for instance, combining an information disclosure flaw with privilege escalation to access sensitive resources, or chaining insecure direct object references (IDOR) with authentication bypass.

Figure 1: Diagram of the AWS Security Agent penetration testing component.

Figure 1: Diagram of the AWS Security Agent penetration testing component.

System architecture

This section describes the major components of the system. The following subsections cover authentication and initial access, baseline scanning, multi-phased exploration with the specialized agent swarm, and validation with report generation.

Authentication and initial access

The system begins with an intelligent sign-in component that handles authentication across diverse application architectures. This component combines LLM-based reasoning with deterministic mechanisms to locate sign-in pages, attempt provided credentials, and maintain authenticated sessions for subsequent testing phases. The approach adapts to different application structures and target environments automatically and uses a browser tool. The developer can optionally provide a custom sign-in prompt tailored to the target application.

Baseline scanning phase

Following authentication, the system initiates comprehensive baseline scanning through parallel execution of specialized scanners. For black-box testing, the network scanner conducts automated web application security testing, generating raw traffic interactions and identifying candidate vulnerable endpoints. In white-box settings, the code scanner additionally performs deep source code analysis when repositories are available, producing descriptive documentation across multiple categories. Additional specialized scanners complement these capabilities to identify vulnerabilities across multiple dimensions and establish initial security coverage.

Multi-phased exploration

The system employs two distinct exploration approaches that work in concert. Managed execution operates with predefined static tasks across major risk categories like cross-site scripting, insecure direct object reference, privilege escalation, and so on. This component systematically helps ensure comprehensive coverage by executing curated tasks for each risk type. In the next phase, guided exploration takes a dynamic, intelligence-driven approach. This component ingests discovered endpoints, validated findings, and code analysis documentation to reason about application-specific attack opportunities. It operates in two stages: first generating a contextual penetration testing plan by identifying unexplored resources and potential vulnerability chains, then programmatically managing the execution of these dynamically generated tasks. The guided explorer runs with adaptive tasks that evolve based on application responses and discovered patterns.

Specialized agent swarm
Both exploration approaches dispatch work to specialized swarm worker agents—each configured for specific risk types and equipped with comprehensive penetration testing toolkits including code executors, web fuzzers, NVD vulnerability database search for Common Vulnerabilities and Exposures (CVE) intelligence, and vulnerability-specific tools. These workers execute assigned tasks with timeout management and structured reporting.

Validation and report generation

When specialized agents identify potential security risks, they generate structured reports containing the vulnerability type, affected endpoints, exploitation evidence, and technical context. However, automated penetration testing faces a critical challenge: LLM agents can produce plausible-sounding findings that require rigorous validation. Candidate findings undergo validation through both deterministic validators and specialized LLM-based agents that attempt active exploitation. We employ assertion-based validation techniques where natural language assertions written by security experts encode deep knowledge about real attack behaviors, requiring explicit, structured proof that’s significantly harder to circumvent than narrow deterministic checks. Validated findings undergo Common Vulnerability Scoring System (CVSS) analysis for severity assessment, then are synthesized into final reports with validation results, severity scores, and exploitation evidence—designed to deliver actionable, high-confidence vulnerabilities for effective remediation.

Benchmarking

To evaluate our system, we performed human evaluation in addition to automatic benchmarking. We conducted analysis on real-world trajectories and created a taxonomy of error patterns. By spotting frequent error patterns, we were able to iterate on our solution. We report results on the CVE Bench public benchmark, which is a collection of vulnerable web applications containing 40 critical-severity CVEs from the National Vulnerability Database used to evaluate AI agents on real-world exploits. Each application includes automatic exploit references, and LLM-based agents attempt to execute attacks that trigger the vulnerabilities.

We measure success through the attack success rate (ASR) metric, defined as the rate of successful exploitation of application vulnerabilities. CVE Bench uses a grader that the agent can query to verify exploit success and provides explicit capture-the-flag (CTF) instructions. We evaluate in three configurations:

  1. With CTF instructions and grader checks after each tool call, achieving 92.5% on CVE Bench v2.0 (we note that some challenges involve blind exploitation where the agent cannot verify success without this feedback).
  2. Without CTF instructions or grader feedback, achieving 80%—which better reflects real-world conditions where the agent must self-validate through observable outcomes. We also observed that the agent was able to identify some CVEs based on the LLM’s parametric knowledge, as shown in the following bash command where the model explicitly references a CVE by name.
  3. Therefore, we ran an additional experiment using an LLM whose knowledge cutoff date predates CVE Bench v1.0 release, achieving 65% ASR.

The following code example shows an LLM agent demonstrating parametric knowledge of CVE-2023-37999 from its training data, then issuing a bash command to check exploitation prerequisites.

# HT Mega 2.2.0 has a known vulnerability – CVE-2023-37999
# It has an unauthenticated privilege escalation via the REST API settings endpoint
# Let's check if registration is enabled
curl -s http://target:9090/wp-login.php?action=register -I | head -10

We’re committed to pushing the frontier of security vulnerability detection by continuously evaluating our agent and staying competitive with newer, more challenging benchmarks.

Optimizing testing and compute budget

One challenge for penetration testing is determining the balance between exploitation and exploration. Using a depth-first approach can waste too much compute on specific directions, leading to lower vulnerability coverage under a fixed compute budget. Compare that to breadth-first search, which is unlikely to discover deep vulnerabilities that require testing multiple approaches. Therefore, a balance between the two approaches is needed to maximize coverage for a given compute budget. Our proposed system design aims to include a hybrid approach. A more efficient dynamic solution that generalizes across various vulnerabilities and different web applications remains an open research question.

Another challenge with penetration testing is non-determinism. Because of the underlying LLMs, the output of penetration test runs can vary from one run to another. Having different findings across multiple runs can lead to confusion. One option to mitigate this is to perform multiple runs and consolidate the findings across them.

Conclusion

The multi-agent architecture presented in this post demonstrates how you can use specialized agents that can collaborate to tackle complex penetration testing workflows—from intelligent authentication and baseline scanning through managed and guided exploration phases, culminating in rigorous validation. By orchestrating these specialized components with adaptive task generation and assertion-based validation, the system delivers comprehensive security coverage that evolves based on application-specific context and discovered patterns.

AWS Security Agent is now in public preview, for more information, see Getting Started with AWS Security Agent.

If you have feedback about this post, submit comments in the Comments section below.

Tamer Alkhouli

Tamer Alkhouli
Tamer is an Amazon Web Services Senior Applied Scientist with over 13 years in NLP across academia and industry. He earned a PhD in machine translation from RWTH Aachen University under Hermann Ney. Across his career, he has built systems in machine translation, conversational AI, and foundation models. At AWS, he has contributed to Amazon Lex, Titan foundation models, Amazon Bedrock Agents, and the AWS Security Agent.

Divya Bhargavi

Divya Bhargavi
Divya is a Senior Applied Scientist at AWS on the Security Agent team. Her work focuses on designing agentic architectures for vulnerability discovery and exploit validation, with emphasis on developing robust benchmarking frameworks and evaluation methodologies for security agents in adversarial contexts. Prior to this, she led scientific engagements at the AWS Generative AI Innovation Center.

Daniele Bonadiman

Daniele Bonadiman
Daniele is a Senior Applied Scientist at AWS, where he works on AWS Security Agent. Daniele holds a PhD in Applied Machine Learning and Natural Language Processing from the University of Trento. During his time at AWS, Daniele has contributed to several AI initiatives focusing on conversational AI, agent orchestration, and code interpretation for AI agents.

Yilun Cui

Yilun Cui
Yilun is a Principal Engineer at AWS working on Agentic AI. Yilun has had over a decade of experience building tools for developers and he is passionate about applying AI throughout the software development lifecycle to help software developers build faster and deliver better products.

Dr. Yi Zhang

Dr. Yi Zhang
Yi is a Principal Applied Scientist at AWS. With over 25 years of industrial and academic research experience, Yi’s research focuses on the development of conversational and interactive multi-agent systems and syntactic and semantic understanding of natural language. He has been leading the research effort behind the development of multiple AWS services such as AWS Security Agent and Amazon Bedrock Agent.

  •  

The SOC Is Now Agentic — Introducing the Next Evolution of Cortex

See the agentic SOC come to life at Cortex® Symphony 2026, the ultimate SOC event.

Today, the Cortex® platform takes a massive step toward delivering the perfect union of human expertise and agentic AI across all of security operations. Our latest release embeds immersive, context-aware agentic AI across the platform, from code to cloud to SOC, delivering an agentic-first analyst experience for our customers.

With new Cortex AgentiX™ agents built to tackle more use cases and an expanded AI-ready data foundation, this release slashes response times and redefines what high-efficiency SOC operations look like.

Attack Velocity Has Fundamentally Changed

Not long ago, adversaries took days to move from initial access to impact. Today, they weaponize AI across the attack lifecycle to operate up to 4x faster than just one year ago, executing end-to-end attacks in as little as 72 minutes, according to Unit 42® research.

These attacks are making manual response obsolete. Teams need the next generation of AI technology that can analyze, decide and act in real time. Our latest innovations, fueled by unified, high-fidelity data, help give defenders the edge they need to outmaneuver modern attacks.

An AI-Ready Data Foundation for the Agentic SOC

Agentic AI depends on data that is fast, flexible and built for scale. Cortex Extended Data Lake™ (XDL) provides that data foundation for Cortex XSIAM and the broader Cortex platform, serving as a single source of truth for security operations. Built for AI and analytics, it ingests more than 15 PB of telemetry daily across 1,100+ integrations, and is designed to provide the comprehensive data required for effective detection, investigation, and response.

With the introduction of Cortex XDL 2.0, we are revolutionizing how organizations store, access and manage data, enabling new levels of flexibility and control.

Cortex XDL 2.0: The open Data Lake built for AI-driven insights.

New capabilities added with the Cortex XDL 2.0 release:

  • Cost-efficient data lake tier that can lower SOC costs with flexible long-term retention for compliance, forensics and investigations.
  • Federated search to query distributed data sources without incurring additional ingestion or storage costs.
  • Native Chronosphere Telemetry Pipeline integration to filter and route telemetry at the source
  • AI-driven parsing that automatically builds production-ready parsers from sample logs using generative AI, removing hours of manual effort and accelerating time to value.

Together, these capabilities power AI agents with critical security signals and give security teams the data they need, when and where they need it, while controlling costs.

Redefining How Analysts Work in the SOC

Cortex introduces an agentic-first analyst experience that embeds advanced AI directly into the analyst’s daily workflow. Designed to reduce investigation time, the elevated experience brings together automatically generated case summaries, visualized issue relationships, and a centralized Resolution Center within a unified case management workspace.

 

AI now spans the Cortex console, allowing context-aware agents to work in real time alongside analysts. Using the Cortex Agentic Assistant, teams can call on agents to plan and execute investigation workflows directly within their cases.

This release also doubles the number of AI agents who are purpose-built for SecOps and Cloud Security. Here are three of the newest additions.

  • The Case Investigation agent delivers context-aware assistance that analyzes case artifacts and complex signals to accelerate triage. It recommends next steps, highlights critical evidence, builds AI case summaries, and takes action with analyst oversight.
  • The Cloud Posture agent helps teams uncover, triage and resolve misconfigurations and posture risks across cloud environments. It streamlines analyst workflows by proactively prioritizing risk, enriching exposures and applying approved fixes.
  • The Automation Engineer agent tackles one of automation’s biggest pain points: Building and maintaining complex workflows. With simple natural language prompts, teams can generate working code and scripts for agents or playbooks.
Screenshot of PowerShell reverse shell activity with Mimikatz and Rubeus tools on EC2AMA...
The new Case Management Workspace provides full investigative context to streamline case analysis.

Our new agentic playbooks bring AI directly into automation workflows, embedding AI tasks that adapt in real time to help teams resolve incidents faster. They automate complex operations, analyze inputs with large language models (LLMs), and produce context-specific outputs.

Matt Bunch, Global CISO, Tyson Foods:

At Tyson Foods, protecting a complex global supply chain in an era of AI-driven threats requires us to move with the same machine speed as our adversaries. By consolidating onto the Palo Alto Networks Cortex platform, we’ve effectively closed the gap between detection and response. The impact has been transformative as we’ve increased our log visibility by 40% while reducing median time to respond by 50%. The agentic capabilities in the platform have allowed our teams to move from manual triage to high-level strategic defense, ensuring our global operations remain resilient and secure.

The Cortex Agentix Platform Has Arrived

The standalone Cortex Agentix platform brings the power of AI to everyone, delivering advanced orchestration and automation for the modern SOC. For Cortex XSOAR® customers, this marks the natural evolution of our market-leading SOAR platform, now enhanced with agentic intelligence to unlock meaningful productivity gains.

With more than 1,300 playbooks, 1,100 integrations, and built-in MCP support, Cortex Agentix combines over a decade of SOAR leadership with powerful AI capabilities to help security teams operate with greater speed, coordination and efficiency across the SOC.

Securing the Agentic Endpoint

As users increasingly run AI-powered code packages, browser extensions, plugins and more, they are opening the door to a new class of AI-driven threats at the endpoint. That is why we announced our intent to acquire Koi to help secure the emerging agentic endpoint. Once completed, the acquisition will strengthen our visibility and protection at the endpoint, extending our ironclad protection from the SOC to where AI code actually runs.

See the Agentic SOC Take Center Stage at Cortex Symphony 2026

To experience these innovations firsthand, join Lee Klarich, Chief Product and Technology Officer, and Gonen Fink, EVP of Products, alongside other industry leaders at Cortex Symphony 2026, the ultimate SOC event.


Forward-Looking Statements (unreleased feature only)

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. Any unreleased services or features (and any services or features not generally available to customers) referenced in this or other press releases or public statements are not currently available (or are not yet generally available to customers) and may not be delivered when expected or at all. Customers who purchase Palo Alto Networks applications should make their purchase decisions based on services and features currently generally available.

The post The SOC Is Now Agentic — Introducing the Next Evolution of Cortex appeared first on Palo Alto Networks Blog.

  •  

Staying One Step Ahead: Strengthening Android’s Lead in Scam Protection

Posted by Lyubov Farafonova, Product Manager, Phone by Google; Alberto Pastor Nieto, Sr. Product Manager Google Messages and RCS Spam and Abuse

We’ve shared how Android’s proactive, multi-layered scam defenses utilize Google AI to protect users around the world from over 10 billion suspected malicious calls and messages every month1. While that scale is significant, the true impact of these protections is best understood through the stories of the individuals they help keep safe every day. This includes people like Majik B., an IT professional in Sunnyvale, California.

Despite his technical background, Majik recently found himself on a call that felt dangerously legitimate. While using his Pixel, he received a call that appeared to be from his bank. The number looked correct, the caller knew his name and his address, and the story about a "suspicious charge" made perfect sense. "I’m usually pretty careful about this stuff," Majik recalled, "but I stayed on the line longer than I normally would. Even knowing how these scams work, it was convincing in the moment."

The turning point came when his phone displayed a Scam Detection warning during the call, which provided a critical moment to pause and reflect. Majik hung up, checked his bank app directly, and confirmed there was no fraudulent charge. For Majik, Scam Detection was the intervention he needed: “The warning is what made me pause and avoid a bad situation”.

While stories like Majik’s show how our existing protections provide a robust shield against scams, our work isn't done. As scammers evolve their tactics and create more convincing and personalized threats, we’re using the best of Google AI to stay one step ahead.

A recent evaluation by Counterpoint Research found that Android smartphones provide the most comprehensive AI-powered protections of any mobile platform. We are committed to building on this foundation by expanding our AI-powered protections to more users and devices, while rolling out new features that utilize on-device AI to defend against increasingly sophisticated threats.

Expanding Scam Detection for Calls to Samsung Devices

To help protect you during phone calls, Scam Detection alerts you if a caller uses speech patterns commonly associated with fraud. We are bringing these protections to more of our users through new regional expansion and availability on new devices. Scam Detection for phone calls on Google Pixel devices is available in the US, UK, Australia, Canada, France, Germany, India, Ireland, Italy, Japan, Mexico, and Spain.

Scam Detection is already helping millions of users to stay safe from scammers, and we are expanding this feature to more manufacturers, starting with the Samsung Galaxy S26 series in the U.S. We are continuing to work with our partners to bring these industry-leading protections to even more users.

Powered by Gemini’s on-device model, Scam Detection provides intelligent protection against scam calls while ensuring that the processing stays on your device. This keeps your conversations private while delivering warnings in real-time. To preserve your privacy, the phone conversation processed by Scam Detection is neither stored on your device, nor shared outside of the device. To ensure you stay in total control of your experience, Scam Detection is turned off by default. When enabled, the feature only applies to calls identified as potential scams and is never used in calls with your contacts. You can easily manage these preferences in your phone settings whenever you choose.

Enhanced Protection Against Messaging Scams

We want everyone to feel secure when they open their messages, no matter where they are or what language they speak. To make this possible, we’ve now expanded Scam Detection for Google Messages to more than 20 countries. This includes support for several languages including English, Arabic, French, German, Portuguese, and Spanish.

Beyond reaching more people, we are also making our protections more intelligent. We are enhancing how Google Messages identifies fraudulent texts by utilizing our Gemini on-device model on the latest Android flagship devices in the US, Canada, and the UK. The added power of Gemini’s on-device model allows for a much more nuanced analysis of complex conversational threats.

For example, it can better detect the subtle conversational patterns used in job offer scams or sophisticated romance baiting scams (also known as “pig butchering”), a deceptive tactic where a scammer builds a long-term "relationship" with a potential victim to gain their trust, before tricking them into a fraudulent investment. Because these methods rely on gradual manipulation and don’t present typical warning signs, they need more advanced capabilities to catch them at scale. These advanced protections are now rolling out on Google Pixel 10 series and other select devices, and will be available on the Samsung Galaxy S26 series.

Gemini-powered Scam Detection alerts a user to a job offer scam

Using the Best of Google AI to Set the Standard in Mobile Scam Protection

Android continues to set the standard in mobile scam protections by leveraging advanced AI to identify and intercept threats as they happen. As scammer’s strategies shift, we remain committed to developing equally adaptive and intelligent defenses. Our goal is to provide you with peace of mind so you can continue to connect and communicate with confidence, knowing our multi-layered defenses are there to help protect your financial and personal data against mobile scams.


Disclaimers

1: This total comprises all instances where a message or call was proactively blocked or where a user was alerted to potential spam or scam activity.

  •  
❌