Read more of this story at Slashdot.

While app performance is often equated with a smooth UI and fast start times, memory serves as the silent foundation upon which these visible metrics are built. It's no secret that we're seeing a shift where device memory is more important than ever. Not only have we made strides in Android memory optimizations with Android 17, we're providing the tooling and API support to help you stay ahead of stricter memory requirements later this year.

To ensure device stability, starting in Android 17, the system will begin enforcing app memory limits based on the device's total RAM. If an app exceeds those limits, Android will kill the process with no associated stack trace.

Optimize image loading

Detect and fix memory leaks with Android Studio

Memory leaks in Android occur when your code holds onto an object's reference long after its lifecycle has ended. This prevents the Garbage Collector (GC) from reclaiming that memory, eventually leading to sluggish performance or OutOfMemoryError (OOM).

Android Studio Panda 3 features a dedicated LeakCanary profiler task, allowing developers to analyze real-time memory leaks and map traces within the IDE.

The LeakCanary profiler task in Android Studio actively moves the memory leak analysis from your device to your development machine, resulting in a significant performance boost during the leak analysis phase as compared to on-device leak analysis.

Additionally, the leak analysis is now contextualized within the IDE and fully integrated with your source code, providing features like go to declaration and other helpful code connections that drastically reduce the friction and time required to investigate and fix memory leaks.

Trim memory when app leaves visible state

Android can reclaim memory from your app or stop your app entirely if necessary to free up memory for critical tasks, as explained in Overview of memory management. Android will usually reclaim memory from your app when it’s not visible to the user, such as by discarding some of your app’s code and data pages in memory or compressing your heap allocations. When the user resumes your app and your app tries to access some memory that’s been reclaimed, the OS will swap that memory back in on demand. This swapping behavior can be slow, and cause unexpected jank or stutters in your app.

If you leave it to the OS to decide what memory to reclaim from your app, you may find that the OS reclaimed memory that you’ll need shortly after resuming your app. Instead, your app can voluntarily discard memory allocations that it can regenerate later, on demand and at a low cost. To do so, you can implement the ComponentCallbacks2 interface. You can implement onTrimMemory in your Activity, Fragment, Service, or even your custom Application class. Using it in the Application class is highly effective for global cache management.

The provided onTrimMemory() callback method notifies your app of lifecycle or memory-related events that present a good opportunity for your app to voluntarily reduce its memory usage.

In terms of memory lifecycle management, your implementation should focus exclusively on TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND. Since Android 14, the system has ceased delivering notifications for other legacy constants, which were formally deprecated in Android 15.

TRIM_MEMORY_UI_HIDDEN: This signal indicates that your application's UI has transitioned out of the user's view. This provides an opportunity to release substantial memory allocations tied strictly to the interface—such as Bitmaps, video playback buffers, or complex animation resources.

TRIM_MEMORY_BACKGROUND: At this level, your process is residing in the background and is now a candidate for termination to satisfy the system's global memory needs. To extend the duration your process remains in the cached state, and reduce the number of app cold starts, you should aggressively release any resources that can be easily reconstructed once the user resumes their session.

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Note: The onTrimMemory integration may depend on SDK support. For instance, certain games rely on their game engine to enable this capability. Please check out the game memory optimization documents.

Advanced memory observability with ProfilingManager

To catch and diagnose memory issues in the field that cannot be reproduced locally, you should leverage the ProfilingManager API. Introduced in Android 15, this advanced observability API allows you to programmatically collect real-user Perfetto profiles.

For teams that lack a dedicated infrastructure to manage and host performance artifacts, Crashlytics is exploring a specialized solution to streamline this workflow. They are inviting developers to provide feedback.

Android 17 introduces new event-driven triggers, most notably TRIGGER_TYPE_OOM and TRIGGER_TYPE_ANOMALY:

• The OOM trigger automatically collects a Java heap dump at the exact moment an OutOfMemoryError crash occurs, providing precise allocation states. A collected OOM profile is provided the next time the app starts and registers the registerForAllProfilingResults callback.
• The Anomaly trigger detects severe performance issues, such as excessive binder spam or breached memory thresholds. The memory anomaly delivers a heap dump just prior to the system terminating the app.

  val profilingManager = 
applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList()  


    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 

    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)

Once you’ve collected the heap dump, you can download the profile from the server, or locally via adb pull and drag and drop the file into the Perfetto UI. To streamline your memory debugging workflow, use the Heap Dump Explorer, this is the new default view for heap dumps in Perfetto UI. This tool provides an intuitive interface for inspecting Java heap dumps, allowing you to visualize object allocation hierarchies, compute retained memory sizes, and identify the shortest path from garbage collection root. By leveraging the Heap Dump Explorer, you can rapidly pinpoint memory leaks, bloated retained objects such as excessive bitmap allocations, and analyze heap object allocations all in one place.

Conclusion

Optimizing bytecode with R8, adopting image loading best practices, and resolving memory leaks are critical steps toward delivering a high-quality user experience while managing resources effectively under pressure. Adopting these proactive measures helps maintain app stability and performance, preventing unexpected terminations while safeguarding user context. To further your performance expertise, explore our revised memory guidance.

Today we're releasing Android 17 and making it available on most supported Pixel devices. Look for new devices running Android 17 in the coming months.

Android 17 marks the start of our transition to an intelligence system, putting your apps at the center. It's shifting to an adaptive-first development standard by introducing mandatory large-screen resizability, all while delivering next-generation privacy, security, media, camera, and performance. We'll cover all that in this post, as well as how we're bringing together next generation tools, libraries, and agent skills to help your apps embrace the opportunity.

Throughout the past year, from our Canary channel to our Beta releases, we’ve collaborated with you in the developer community to build a platform you and your users can trust. To that end, this moment marks the availability of the source code at the Android Open Source Project (AOSP). This allows you to examine the source code for a deeper understanding of how Android works.

Let's dive deeper into Android 17.

An intelligence system

With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system. It's about delivering new helpful experiences that anticipate user needs, and it brings more opportunities for engagement with your apps. To that end, Android 17 expands the capabilities of AppFunctions, a platform API with a corresponding Jetpack library. It allows you to contribute your app's unique capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. AI agents and assistants (like Google Gemini) can discover and execute AppFunctions to perform workflows on behalf of the user with direct access to the app's local state.

The Jetpack library, currently in alpha, makes adding AppFunctions as easy as annotating a class and adding KDoc comments.

/**
 * A note app's [AppFunction]s.
 */
class NoteFunctions(
    private val noteRepository: NoteRepository
) {
    /**
     * Adds a new note to the app.
     *
     * @param appFunctionContext The execution context.
     * @param title The title of the note.
     * @param content The note's content.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createNote(
        appFunctionContext: AppFunctionContext,
        title: String,
        content: String
    ): Note {
        return noteRepository.createNote(title, content)
    }
}

We’ve also launched an AppFunctions agent skill that analyzes your app’s key workflows, automatically generates the required Kotlin code, optimizes your KDocs for LLM tool-calling, and provides ADB commands for testing and debugging.

The Gemini integration is currently in a private preview with trusted testers, but you can begin preparing your apps now. In addition to ADB commands to execute your AppFunctions, we've provided a test agent app that includes an interface to discover and execute your app functions and simulate an AI agent integration. Join our integration early access program at goo.gle/eap-af for a chance to be among the first apps to deploy AppFunctions to production.

Adaptive-first

Your users no longer rely on a single form factor; they transition between phones, foldables, tablets, laptops, automotive displays, and immersive XR environments. Now, with over 580 million large screen devices in the hands of users and the forthcoming launch of Googlebooks, the next generation of ChromeOS built on the Android stack, adaptive is no longer just a technical goal. It’s a massive opportunity to reach highly engaged users, which is one of the reasons we're shifting to an adaptive-first development standard.

No resizability/orientation restrictions on large screens

To ensure apps deliver a premium experience across all form factors, including mobile devices running in desktop mode on connected displays, Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp) for apps targeting API level 37. The system will ignore legacy manifest attributes and runtime APIs, including screenOrientation, setRequestedOrientation(), resizeableActivity=false, and aspect ratio constraints (minAspectRatio/maxAspectRatio). Games (based on app category in Google Play) remain exempt. Your app must be ready to adapt to any window size, respect the user's preferred device posture, and support free-form windowing natively.

Next-gen multitasking: App Bubbles, Bubble Bar, and desktop interactive PiP

Android 17 introduces powerful new windowing capabilities that redefine how users multitask, demanding even greater layout flexibility from your apps:

• App Bubbles: Moving beyond the messaging bubbles API, users can now transform any app into a floating bubble by long-pressing its icon on the launcher. This feature is available across phones, foldables, and tablets, enabling lightweight multitasking for any workflow.
• The Bubble Bar: On large screens (tablets and foldables), the system taskbar now includes a dedicated Bubble Bar to organize, transition between, and dock these floating app bubbles.
• Desktop interactive PiP: In desktop environments, Android 17 introduces interactive Picture-in-Picture (PiP). Unlike traditional PiP windows which are read-only, these pinned windows remain fully interactive while staying always-on-top of other application windows.

App Bubbles and Bubble Bar in action

Activity recreation updates

To prevent disruptive state loss and stutter, Android 17 updates the default behavior for Activity recreation. The system will no longer restart activities by default for typical configuration changes that do not require a full UI redraw (including CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN, and CONFIG_COLOR_MODE).
Instead, running activities will receive these updates via onConfigurationChanged(), enabling smooth transitions. If your application explicitly relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute.

Continue On

Android 17 adds Continue On to help users seamlessly transition a task between Android devices. The user sees a suggestion for the most recently opened app from their mobile device in their tablet taskbar, providing a one-tap affordance to launch the app and deep-link where they left off. Continue on can support app-to-web transitions, including falling back to using the web if the app isn't installed.

Handoff Suggestion on a Tablet

class MyHandoffActivity : Activity() {

    ...

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // Do stuff
    ...
    // Enable handoff
    setHandoffEnabled(true, null)
  }

  // Override and implement onHandoffActivityDataRequested
  override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData {
    // Create and return handoff data
  }
}

Go adaptive-first with Jetpack Compose

To help you adapt your apps to meet the new Android 17 requirements, we've launched the Jetpack Compose adaptive skill. This AI-powered developer workflow helps you implement the best adaptive practices:

• Adaptive navigation: Automatically transition between bottom navigation bars on mobile and edge-anchored navigation rails on large screens using NavigationSuiteScaffold from the Material 3 Adaptive library.
• Multi-pane layouts: Implement list-detail and supporting pane layouts natively using Navigation 3 Scenes (ListDetailSceneStrategy and SupportingPaneSceneStrategy) instead of fragile fragment transactions.
• FlexBox & Grid APIs: Utilize Compose 1.11's dynamic layout components to easily adjust row and column spans on the fly, ensuring your content always fills the space beautifully.
• Advanced non-touch input: Leverage Compose 1.11's enhanced trackpad and mouse support, including native focus rings and new APIs (like TrackpadInjectionScope and performTrackpadInput) to easily test and deliver a true "laptop-class" experience on Googlebooks and Desktop Mode.
• Dynamic window states: Leverage Compose's reactive state model to seamlessly adapt your UI when the app transitions from full screen to a floating App Bubble or an interactive Desktop PiP window, ensuring a premium experience even at minimal dimensions.

Android is Compose-first

Compose offers the easiest way to build adaptive apps, and that's just one of the many reasons we believe that all Android UI should be built with Compose. To that end, Android development is now Compose-first. All new Android APIs, libraries, tools, and developer guidance will be built exclusively for Jetpack Compose. Legacy View components (in the android.widget package) and View-based Jetpack libraries (like Fragments, RecyclerView, and ViewPager) are now in maintenance mode. They will receive only critical bug fixes, and no new features.

TIP
Ready to migrate? Use our AI-driven XML to Compose Migration Skill to automatically analyze your legacy View layouts and convert them into highly-adaptive Compose code.

Performance & efficiency

App performance means a smooth user interface, fast app start times, and efficient multitasking; Android 17 has impactful improvements in all of these areas.

App memory limits

Memory usage is one of the silent foundations of overall performance. When a foreground app or service grows unchecked, memory management spikes CPU and battery utilization and eventually leads to the termination of other well-behaved cached apps and background jobs, ultimately forcing slower cold starts and impaired multitasking. 

Starting in Android 17, the system will enforce strict app memory limits based on a device's total RAM, abruptly terminating offending processes. New things to help you navigate these tighter requirements:

• R8 Optimizer: The R8 optimizer significantly reduces your app's bytecode memory footprint by shrinking classes, methods, and fields into shorter names, and stripping out unused code and resources. Use R8 in full mode along with the new R8 configuration analyzer to make sure your app is getting the most from R8.
  

• LeakCanary in Android Studio Panda: The profiler now features native LeakCanary integration as a dedicated task, fully integrated with your IDE and source code.
• ApplicationExitInfo: If your app is terminated by these limits, getDescription() from ApplicationExitInfo will return "MemoryLimiter:AnonSwap".
• On-Device Anomaly Detection: Part of ProfilingManager, you can leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached.

val profilingManager = applicationContext
   .getSystemService(ProfilingManager::class.java)

val triggers = ArrayList<ProfilingTrigger>().apply {
  add(ProfilingTrigger.Builder(
    ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build())
}
profilingManager.addProfilingTriggers(triggers)

And, we're working to surface more in-field memory metrics to you within Google Play Console.

Generational garbage collection

Android 17 introduces more frequent, less resource-intensive young-generation collections to ART's Concurrent Mark-Compact garbage collector (GC). By separating short-lived objects from stable, long-lived ones, the system runs frequent, lightweight "young-generation" sweeps rather than expensive full-heap scans, drastically reducing CPU usage, power drain, and UI stutter. Our testing has shown significant improvements in GC interference with application threads and a reduction in the maximum memory resident set size (RSS). ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates.

Lock-Free MessageQueue

For apps targeting SDK 37 or higher, the core android.os.MessageQueue now implements a lock-free architecture, significantly reducing missed frames, improving app startup time, and radically improving the performance of busy queues in multithreaded scenarios. Note: This can break apps that use reflection on private MessageQueue fields and methods.  The peekWhen and poll APIs have been added to TestLooperManager for instrumentation testing without relying on MessageQueue internals.

Static final fields now truly final

Starting from Android 17, apps targeting SDK 37 or higher won’t be able to modify “static final” fields, allowing the runtime to apply performance optimizations more aggressively. An attempt to do so via reflection (or deep reflection) will lead to an IllegalAccessException being thrown. Modifying them via JNI’s SetStatic<Type>Field methods family will immediately crash the application.

Custom notification view restrictions

To reduce memory usage we are further restricting the size of custom notification views. This update closes a loophole that allows apps to bypass existing limits using URIs. This behavior is gated by the target SDK version and takes effect for apps targeting API 37 and higher.

Privacy & Security

Maintaining user trust is at the heart of the Android ecosystem. Android 17 introduces robust features that protect sensitive data while simplifying user experiences.

Privacy-preserving choices

Historically, apps required broad, permanent permissions to access information like contacts, precise location and media files. Android 17 continues the shift toward privacy-preserving choices that grant temporary, session-based access only to the data the user explicitly selects:

• System-Level Contact Picker: Utilizing ACTION_PICK_CONTACTS, apps can request temporary access only to specific fields (e.g., email or phone number) chosen by the user, eliminating the need for the broad READ_CONTACTS permission. It also fully supports work/personal profile separation.
• Customizable Photo Picker aspect ratio: UsingPhotoPickerUiCustomizationParams, you can customize the system photo picker to show thumbnails in portrait mode. This is perfect for apps that always display photos and videos in portrait such as video based social media apps.
• System-rendered Location Button: A new system-rendered location button that you can embed in your app grants precise location access for the current session only.
• EyeDropper API: A new system-level API, ACTION_OPEN_EYE_DROPPER, allows your app to create a system-powered eyedropper enabling the user to select color from any pixel on the display. This provides a secure, privacy-preserving color-picking experience that eliminates the need for broad, sensitive screen capture or media projection permissions.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
   if (result.resultCode == Activity.RESULT_OK) {
       val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
       // Use the picked color in your app
   }
}
fun launchColorPicker() {
   val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
   eyeDropperLauncher.launch(intent)
}

Picking a color from anywhere on the screen with the system EyeDropper

Local network access

Apps targeting Android 17 now either require the ACCESS_LOCAL_NETWORK runtime permission or the use of system-mediated, privacy-preserving device pickers for local network communication, such as talking to smart home devices or casting receivers. Because ACCESS_LOCAL_NETWORK falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions will not be prompted again.

SMS OTP protection

Android 17 expands SMS one-time-password (OTP) protection by delaying access to SMS messages for three hours:

• WebOTP Format: Delayed for all apps that are not the intended recipient (domain mismatch).
• Standard SMS OTP: Delayed for all apps targeting SDK 37+.
• Exemptions: Default SMS, assistant, and connected companion apps are exempt. Apps are strongly encouraged to migrate to the SMS Retriever or SMS User Consent APIs.

Post-Quantum Cryptography (PQC)

Android 17 is ready for the next generation of cryptographic security:

• Keystore Integration: Supported devices can generate ML-DSA (Module-Lattice-Based Digital Signature Algorithm) keys in secure hardware to produce quantum-safe signatures, exposed via standard JCA APIs.
• Hybrid APK Signing: Introducing the v3.2 APK Signature Scheme, which combines classical signatures with ML-DSA signatures to secure app delivery.

Safer native dynamic code loading 

Smarter password protection for physical inputs

With Android 17, we're making it safer to enter passwords, PINs, and other secrets when using a physical keyboard by no longer showing the last typed character by default.

Users can still easily customize these display settings to match their preferences (availability may vary by device manufacturer).

These enhanced privacy protections are automatically supported byAndroid's built-in SDK components and will be supported in Compose 1.12 for SecureTextFields.

Media and camera features that empower creators and delight users

Android 17 introduces new creator features that give access to pro-quality cameras and media, all while improving the experience for consumers.

• Eclipsa Video: HDR video standard built upon the SMPTE ST 2094-50 specification that introduces new metadata to help devices adapt content for their display headroom and ambient light conditions, as well as improve the simultaneous display of standard and HDR content.
• RAW14 image format: New support for the RAW14 image format provides a way for your professional camera app to capture the highest level of detail and color depth from compatible camera sensors.
• Vendor-defined camera extensions: Vendor-defined extensions enable hardware partners to define and implement custom camera extension modes, providing access to the best and latest camera features.
• Extended HE-AAC software encoder: A new system-provided Extended HE-AAC software encoder, supports both low and high bitrates using unified speech and audio coding, providing significantly better audio quality for voice messages in low-bandwidth conditions, including support for loudness metadata.
• Versatile Video Coding (H.266): Enables OEMs to add codec support by defining the video/vvc MIME type in MediaFormat, adding new VVC profiles in MediaCodecInfo, and integrating support into MediaExtractor.
• Camera device type: New APIs that query the underlying device type to identify if a camera is built-in hardware, an external USB webcam, or a virtual camera.
• Constant Quality for Video Recording: SetVideoEncodingQuality in MediaRecorder configures a constant quality (CQ) mode for video encoders to ensure uniform visual fidelity across the entire video.

Better support for hearing aids

• Bluetooth LE Audio hearing aid support: Android now includes a specific device category for Bluetooth Low Energy (BLE) Audio hearing aids with the new AudioDeviceInfo.TYPE_BLE_HEARING_AID constant, so your app can distinguish hearing aids from regular headsets to provide a tailored experience for users with assistive listening devices.
• Granular audio routing for hearing aids: Android 17 allows users to independently manage where specific system sounds are played. They can choose to route notifications, ringtones, and alarms to connected hearing aids or the device's built-in speaker, helping to avoid unwanted in-ear interruptions while maintaining a Bluetooth connection for hearing aid management apps.

CameraX and Media3

CameraX and Media3 have been updated for Android 17. They are there to do the heavy lifting, smoothing the rough edges of media development and simplifying building reliable camera capture, smooth media playback, and creative and complex editing experiences.

We've released an agent skill that can migrate legacy Android camera implementations (Camera1 or raw Camera2 APIs) to CameraX.

Note: You'll need to update your CameraX version to either 1.5.2 or 1.6.0+ to avoid a crash related to an added dynamic range mode on Android 17 devices.

Get your apps, libraries, tools, and game engines ready!

If you develop an Android SDK, library, tool, or game engine, it's critical to prepare any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your downstream developers know if updates are needed to fully support Android 17.

Testing involves installing your production app or a test app making use of your library or engine using Google Play or other means onto a device or emulator running Android 17 Beta 4. Work through all your app's flows and look for functional or UI issues. Each release of Android contains platform changes that improve privacy, security, and overall user experience; review the app impacting behavior changes for apps running on and targeting Android 17 to focus your testing, including the following:

• Resizability on large screens: Once you target Android 17 (SDK 37), you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens.
• Dynamic code loading: If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.
• Enable CT by default: Certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)
• Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORKpermission for broad, persistent access.
• Background audio hardening: Starting in Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs. Based on your feedback, we’ve made some changes since beta 2, including targetSDK gating while-in-use FGS enforcement and exempting alarm audio. Full details available in the updated guidance.
• NPU access declaration: Apps targeting Android 17 that need to directly access the NPU must declare FEATURE_NEURAL_PROCESSING_UNIT in their manifest to avoid being blocked from accessing the NPU. This includes apps that use the LiteRT NPU delegate, vendor-specific SDKs, as well as the deprecated NNAPI.

Get started with Android 17

Your Pixel device should get Android 17 shortly if you haven't already been on the Android Beta. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on Android 17 Beta 4.1 and have not yet taken an Android 17 QPR1 beta, you can opt out of the program and you will then be offered the release version of Android 17 over the air.

Getting the Android 17 beta on partner devices

Android 17 is available in beta on handset, tablet, and foldable form factors from partners including Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo, and Xiaomi.

For the best development experience with Android 17, we recommend that you use the latest Canary build of Android Studio Quail. Once you’re set up, here are some of the things you should do:

Test your current app for compatibility, learn whether your app is affected by changes in Android 17, and install your app onto a device or Android Emulator running Android 17 and extensively test it.

Thank you again to everyone who participated in our Android developer preview and beta program. We're looking forward to seeing how your apps take advantage of the updates in Android 17, and have plans to bring you updates in a fast-paced release cadence going forward.

For complete information on Android 17 please visit the Android 17 developer site.

Note: This joint Cybersecurity Advisory is being published as an addition to the Cybersecurity and Infrastructure Security Agency (CISA) May 6, 2025, joint fact sheet Primary Mitigations to Reduce Cyber Threats to Operational Technology and European Cybercrime Centre’s (EC3) Operation Eastwood, in which CISA, Federal Bureau of Investigation (FBI), Department of Energy (DOE), Environmental Protection Agency (EPA), and EC3 shared information about cyber incidents affecting the operational technology (OT) and industrial control systems (ICS) of critical infrastructure entities in the United States and globally.

FBI, CISA, National Security Agency (NSA), and the following partners—hereafter referred to as “the authoring organizations”—are releasing this joint advisory on the targeting of critical infrastructure by pro-Russia hacktivists:

• U.S. Department of Energy (DOE)
• U.S. Environmental Protection Agency (EPA)
• U.S. Department of Defense Cyber Crime Center (DC3)
• Europol European Cybercrime Centre (EC3)
• EUROJUST – European Union Agency for Criminal Justice Cooperation
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Canadian Centre for Cyber Security (Cyber Centre)
• Canadian Security Intelligence Service (CSIS)
• Czech Republic Military Intelligence (VZ)
• Czech Republic National Cyber and Information Security Agency (NÚKIB)
• Czech Republic National Centre Against Terrorism, Extremism, and Cyber Crime (NCTEKK)
• French National Cybercrime Unit – Gendarmerie Nationale (UNC)
• French National Jurisdiction for the Fight Against Organized Crime (JUNALCO)
• German Federal Office for Information Security (BSI)
• Italian State Police (PS)
• Latvian State Police (VP)
• Lithuanian Criminal Police Bureau (LKPB)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• Romanian National Police (PR)
• Spanish Civil Guard (GC)
• Spanish National Police (CNP)
• Swedish Polisen (SC3)
• United Kingdom National Cyber Security Centre (NCSC-UK)

The authoring organizations assess pro-Russia hacktivist groups are conducting less sophisticated, lower-impact attacks against critical infrastructure entities, compared to advanced persistent threat (APT) groups. These attacks use minimally secured, internet-facing virtual network computing (VNC) connections to infiltrate (or gain access to) OT control devices within critical infrastructure systems. Pro-Russia hacktivist groups—Cyber Army of Russia Reborn (CARR), Z-Pentest, NoName057(16), Sector16, and affiliated groups—are capitalizing on the widespread prevalence of accessible VNC devices to execute attacks against critical infrastructure entities, resulting in varying degrees of impact, including physical damage. Targeted sectors include Water and Wastewater Systems, Food and Agriculture, and Energy.

The authoring organizations encourage critical infrastructure organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of pro-Russia hacktivist-related incidents. For additional information on Russian state-sponsored malicious cyber activity, see CISA’s Russia Threat Overview and Advisories webpage.

Download the PDF version of this report:

Background and Development of Pro-Russia Hacktivist Groups

Over the past several years, the authoring organizations have observed pro-Russia hacktivist groups conducting cyber operations against numerous organizations and critical infrastructure sectors worldwide. The escalation of the Russia-Ukraine conflict in 2022 significantly increased the number of these pro-Russia groups. Consisting of individuals who support Russia’s agenda but lack direct governmental ties, most of these groups target Ukrainian and allied infrastructure. However, among the increasing number of groups, some appear to have associations with the Russian state through direct or indirect support.

Cyber Army of Russia Reborn

The authoring organizations assess that the Russian General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455—tracked in the cybersecurity community under several names (see Appendix B: Additional Designators Used for Cited Groups)—is likely responsible for supporting the creation of CARR —also known as “The People’s Cyber Army of Russia”—in late February or early March of 2022. Actors suspected to be from GRU unit 74455 likely funded the tools CARR threat actors used to conduct distributed denial-of-service (DDoS) attacks through at least September 2024.

In April 2022, the group began using a new Telegram channel featuring the name “CyberArmyofRussia_Reborn” to organize and plan group actions. The channel creators recruited actors to use CARR as an unattributable platform for conducting cyber activities beneath the level of an APT, aimed at deterring anti-Russia rhetoric. CARR threat actors presented themselves as a group of pro-Russia hacktivists supporting Russia’s stance on the Ukrainian conflict, and they soon began claiming responsibility for DDoS attacks against the U.S. and Europe for supporting Ukraine.

CARR documented these actions through embellished images and videos shared on their social media channels, promoting Russian ideology, disseminating talking points, and publicizing leaked information from hacks attributed to Russian state threat actors.

In late 2023, CARR expanded their operations to include attacks on industrial control systems (ICS), claiming an intrusion against a European wastewater treatment facility in October 2023. In November 2023, CARR targeted human-machine interface (HMI) devices, claiming intrusions at two U.S. dairy farms.

The authoring organizations assess that by late September 2024, CARR channel administrators became dissatisfied with the level of support and funding provided by the GRU. This dissatisfaction led CARR administrators and an administrator from another hacktivist group, NoName057(16), to create the Z-Pentest group, employing the same tactics, techniques, and procedures (TTPs) as CARR but separate from GRU involvement.

NoName057(16)

The authoring organizations assess that the Center for the Study and Network Monitoring of the Youth Environment (CISM), established on behalf of the Kremlin, created NoName057(16) as a covert project within the organization. Senior executives and employees within CISM developed and customized the NoName057(16) proprietary DDoS tool DDoSia, paid for the group’s network infrastructure, served as administrators on NoName057(16) Telegram channels, and selected DDoS targets.

Active since March 2022, NoName057(16) has conducted frequent DDoS attacks against government and private sector entities in North Atlantic Treaty Organization (NATO) member states and other European countries perceived as hostile to Russian geopolitical interests. The group operates primarily through Telegram channels and used GitHub, alongside various websites and repositories, to host DDoSia and share materials and TTPs with their followers. 

In 2024, NoName057(16) began collaborating closely with other pro-Russia hacktivist groups, operating a joint chat with CARR by mid-2024. In July 2024, NoName057(16) jointly claimed responsibility with CARR for an alleged intrusion against OT assets in the U.S. The high degree of cooperation with CARR likely contributed to the formation of Z-Pentest, which is composed of actors and administrators from both teams, in September 2024.

Z-Pentest

Established in September 2024, Z-Pentest is composed of members from CARR and NoName057(16). The group specializes in OT intrusion operations targeting globally dispersed critical infrastructure entities. Additionally, the group uses “hack and leak” operations and defacement attacks to draw attention to their pro-Russia messaging. Unlike other pro-Russia hacktivist groups, Z-Pentest largely avoids DDoS activities, claiming OT intrusions as attempts to garner more attention from the media.

Shortly after Z-Pentest’s inception, the group announced alliances with CARR and NoName057(16), possibly to leverage the other groups’ subscribers to grow the new channel. In March 2025, Z-Pentest posted evidence claiming OT device intrusions to their channel using a NoName057(16) cyberattack campaign hashtag. Similarly, in April 2025, Z-Pentest shared a video purporting defacement of an HMI by changing system names to NoName057(16) and CARR references. Z-Pentest continues to create new alliances with other groups, like Sector16, to continue growing their subscriber base and incidentally propagate TTPs with new partners.

Sector16

Formed in January 2025, Sector16 is a novice pro-Russia hacktivist group that emerged through collaboration with Z-Pentest. Sector16 actively maintains an online presence, including a public Telegram channel where they share videos, statements, and claims of compromising U.S. energy infrastructure. These communications often align with pro-Russia narratives and reflect their self-proclaimed support for Russian geopolitical objectives.

Members of Sector16 may have received indirect support from the Russian government in exchange for conducting specific cyber operations that further Russian strategic goals. This aligns with broader Russian cyber strategies that involve leveraging non-state threat actors for certain cyber activities, adding a layer of deniability.

Technical Details

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 18. See the MITRE ATT&CK Tactics and Techniques section of this advisory for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

TTP Overview

Pro-Russia hacktivist groups employ easily disseminated and replicated TTPs across various entities, increasing the likelihood of widespread adoption and escalating the frequency of intrusions. These groups have limited capabilities, frequently misunderstanding the processes they aim to disrupt. Their apparent low level of technical knowledge results in haphazard attacks where actors intend to cause physical damage but cannot accurately anticipate actual impact. Despite these limitations, the authoring organizations have observed these groups willfully cause actual harm to vulnerable critical infrastructure.

Pro-Russia hacktivist groups use the TTPs in this Cybersecurity Advisory to target virtual network computing (VNC)-connected HMI devices. These groups are primarily seeking notoriety with their actions. While they have caused damage in some instances, they regularly make false or exaggerated claims about their attacks on critical infrastructure to garner more attention. They frequently misrepresent their capabilities and the impacts of their actions, portraying minor incursions as significant breaches, but such incursions can still lead to lost time and resources for operators remediating systems.

Additionally, pro-Russia hacktivists use an opportunistic targeting methodology. They leverage superficial criteria, such as victim availability and existing vulnerabilities, rather than focusing on strategically significant entities. Their lack of strategic focus can lead to a broad array of targets, ranging from water treatment facilities to oil well systems. Pro-Russia hacktivists have demonstrated a pattern of frequently taking advantage of the widespread availability of vulnerable VNC connections. While system owners typically use VNC connections for legitimate remote system access functions, threat actors can maliciously use these connections to broadly target numerous platforms and services. Consequently, these groups can indiscriminately compromise critical infrastructure entities, including those in the Water and Wastewater, Food and Agriculture, and Energy Sectors.

Pro-Russia hacktivist groups have successfully targeted supervisory control and data acquisition (SCADA) networks using basic methods, and in some cases, performed simultaneous DDoS attacks against targeted networks to facilitate SCADA intrusions. As recently as April 2025, threat actors used the following unsophisticated TTPs to access networks and conduct SCADA intrusions:

• Scan for vulnerable devices on the internet [T0883] with open VNC ports [T1595.002].
• Initiate temporary virtual private server (VPS) [T1583.003] to execute password brute force software.
• Use VNC software to access hosts [T1021.005].
• Confirm connection to the vulnerable device [T0886].
• Brute force the password, if required [T1110.003].
• Gain access to HMI devices [T0883], typically with default [T0812], weak, or no passwords [T0859].
• Log the confirmed vulnerable device IP address, port, and password.
• Using the HMI graphical interface [T0823], capture screen recordings or intermittent screenshots while conducting the following actions, intending to affect productivity and cause additional costs [T0828]:
  • Modify usernames/passwords [T0892];
  • Modify parameters [T0836];
  • Modify device name [T0892];
  • Modify instrument settings [T0831];
  • Disable alarms [T0878];
  • Create loss of view (a technique that mandates local hands-on operator intervention) [T0829]; and/or
  • Device restart or shutdown [T0816].
• Disconnect from the device, ending the VNC connection.
• Research the compromised device company after the intrusion [T1591].

Propagation

To reach a wider audience, pro-Russia hacktivist groups work together, amplify each other’s posts, create additional groups to amplify their own posts, and likely share TTPs. For example, Z-Pentest jointly claimed intrusion of a U.S. system with Sector16. Sector16 later began posting additional intrusions for which the group claimed sole responsibility. It is likely that these and similar groups will continue to iterate and share these methods to disrupt critical infrastructure organizations.

Reconnaissance and Initial Access

The threat actors’ intrusion methodology is relatively unsophisticated, inexpensive to execute, and easy to replicate. These pro-Russia hacktivist groups abuse popular internet-scraping tools, such as Nmap or OPENVAS, to search for visible VNC services and use brute force password spraying tools to access devices via known default or otherwise weak credentials. Threat actors typically search for these services on the default port 5900 or other nearby ports (5901-5910). Their goal is to gain remote access to HMI devices connected to live control networks.

Once threat actors obtain access, they manipulate available settings from the graphical user interface (GUI) on the HMI devices, such as arbitrary physical parameter and setpoint changes, or conduct defacement activities. Because pro-Russia hacktivist groups seem to lack sector-specific expertise or cyber-physical engineering knowledge, they currently cannot reliably estimate the true impact of their actions. Regardless of outcome, pro-Russia hacktivist groups often post images and screen recordings to their social media platforms, boasting the compromises and exaggerating impacts to garner attention from their peers and the media.

Impact

While pro-Russia hacktivist groups currently demonstrate limited ability to consistently cause significant impact, there is a risk that their continued attacks will result in further harm or grievous physical consequences. Attacks have not yet caused injury; however, the attacks against occupied factories and community facilities demonstrate a lack of consideration for human safety.

Victim organizations reported that the most common operational impact caused by these threat actors is a temporary loss of view, necessitating manual intervention to manage processes. However, any modifications to programmatic and systematic procedures can result in damage or disruption, including substantial labor costs from hiring a programmable logic controller programmer to restore operations, costs associated with operational downtime, and potential costs for network remediation.

MITRE ATT&CK Tactics and Techniques

See Table 1 to Table 10 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Incident Response

If organizations find exposed systems with weak or default passwords, they should assume threat actors compromised the system and begin the following incident response protocols:

1. Determine which hosts were compromised and isolate them by quarantining or taking them offline.
2. Initiate threat hunting activities to scope the intrusion. Collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.
3. Reimage compromised hosts.
4. Provision new account credentials.
5. Report the compromise to CISA, FBI, and/or NSA. See the Contact Information section of this advisory.
6. Harden the network to prevent additional malicious activity. See the Mitigations section of this advisory for guidance.

Mitigations

OT Asset Owners and Operators

The authoring organizations recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture based on the threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

• Reduce exposure of OT assets to the public-facing internet. When connected to the internet, OT devices are easy targets for malicious cyber threat actors. Many devices can be found by searching for open ports on public IP ranges with search engine tools to target victims with OT components [CPG 3.S].
  • Asset owners should use attack surface management services and web-based search platforms to scan the internet. This mitigation can help identify if there are VNC systems exposed within the IP ranges they own, especially for connections set up by third parties.
    Note: For more information on attack surface management, see CISA’s Internet Exposure Reduction Guidance, CISA’s Cyber Hygiene Services for U.S. critical infrastructure, and NSA’s Attack Surface Management for the U.S. Defense Industrial Base.
  • Implement network segmentation between IT and OT networks. Segmenting critical systems and introducing a demilitarized zone (DMZ) for passing control data to enterprise logistics reduces the potential impact of cyber threats and the risk of disruptions to essential OT operations [CPG 3.I].
  • Consider implementing a firewall and/or virtual private network if exposure to the internet is necessary for controlling access to devices.
    • Consider disabling public exposure by default and implementing time-limited remote access to reduce the amount of time systems are exposed.
    • Restrict and monitor both inbound and outbound traffic at OT perimeter firewalls. Configure OT perimeter firewalls to enforce a default-deny policy for all traffic. Asset owners should explicitly permit authorized destinations and protocols based on operational requirements.
    • Implement strict egress filtering to prevent unauthorized data exfiltration or command-and-control callbacks.
    • Regularly audit firewall rulesets and monitor outbound traffic patterns for anomalies indicative of threat actor activity, such as beaconing or unexpected protocol usage.
• Adopt mature asset management processes, including mapping data flows and access points. Generating a complete picture of both OT and IT assets provides visibility to operators and management, allowing organizations to monitor and assess deviations for criticality [CPG 2.A].
  • Keep remote access services updated with the latest version available and ensure all systems and software are up to date with patches and necessary security updates.
    • Keep VNC systems updated with the latest version available.
  • Refer to the joint Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators to help with reducing cybersecurity risk by identifying which assets within their environment should be secured and protected.
• Ensure OT assets use robust authentication procedures.
  • Many devices lack robust authentication and authorization. Devices with weak authentication are vulnerable targets to threat actors using credential theft techniques.
  • Implement MFA where possible. Where MFA is not feasible, use strong, unique passwords. Apply password standards for operator-accessible services on underlying OT assets, as well as network devices protecting those services. This is especially important for services that require internet accessibility [CPG 3.A] [CPG 3.B] [CPG 3.C] [CPG 3.F].
  • Establish an allowlist that permits only authorized device IP addresses and/or media access control addresses. The allowlist can be refined to operator working hours to further obstruct malicious threat actor activity; organizations are encouraged to establish monitoring and alerting for access attempts not meeting these criteria [CPG 3.E].
  • Disable any unused authentication methods, logic, or features, such as default authentication keys and default passwords. Block all unused high ephemeral ports and monitor for attempted connections using standard protocols on non-standard ports [CPG 3.R].
  • Authenticate all access to field controllers before authorizing access to, or modification of, a device’s state, logic, program, or filesystems.
• Enable control system security features that can separate and audit view and control functions. Limiting remotely accessible or default user accounts to “view-only” removes the potential for impact without exploiting a vulnerability [CPG 3.G].
• Implement and practice business recovery/disaster recovery plans. Plans should also take into consideration redundancy, fail-safe mechanisms, islanding capabilities, backup restoration, and manual operation.
  • Include scenarios that necessitate switching to manual operations. Maintaining the capability of an organization to revert to manual controls to quickly restore operations is vital in the immediate aftermath of a cyber incident [CPG 6.A].
  • Create backups of the engineering logic, configurations, and firmware of HMIs to enable fast recovery. Organizations should routinely test backups and standby systems to ensure safe manual operations in the event of an incident [CPG 3.O].
• Collect and monitor the traffic of OT assets and networking devices. This includes unusual logins or unexpected protocols communicating over the internet, and functions of ICS management protocols that change an asset’s operating mode or modify programs.
• Review configurations for setpoint ranges or tag values to stay within safe ranges and establish alerting for deviations.
• Take a proactive approach in the procurement process by following the guidance outlined in the joint guide Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.

OT Device Manufacturers

Although critical infrastructure organizations can take steps to mitigate risks, it is ultimately the responsibility of OT device manufacturers to build products that are secure by design. The authoring organizations urge device manufacturers to take ownership of the security outcomes of their customers in line with the joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software.

• Eliminate default credentials and require strong passwords. The use of default credentials is a top weakness threat actors exploit to gain access to systems.
• Mandate MFA for privileged users. Changes to engineering logic or configurations are safety-impacting events in critical infrastructure. MFA should be available for safety critical components at no additional cost.
• Practice secure by default principles. OT components were initially designed without public internet connectivity in mind. When internet connection becomes necessary, implementing additional security measures is essential to safeguard these systems. Manufacturers should recognize insecure states and promptly inform users so they can make informed risk decisions.
  • Include logging at no additional charge. Change and access control logs allow operators to track safety-impacting events in their critical infrastructure. These logs should be available for no cost and use open standard logging formats.
• Publish Software Bill of Materials (SBOMs). Vulnerabilities in underlying software libraries can affect a wide range of devices. Without an SBOM, it is nearly impossible for a critical infrastructure system owner to measure and mitigate the impact of a vulnerability on their existing systems. See CISA’s SBOM webpage for more information.

Additionally, see CISA’s Secure by Design Alert on how software manufacturers can shield web management interfaces from malicious cyber activity. By using secure by design tactics, software manufacturers can make their product lines secure “out of the box” without requiring customers to spend additional resources making configuration changes, purchasing tiered security software and logs, monitoring, and making routine updates.

For more information on secure by design, see CISA’s Secure by Design webpage.

Validate Security Controls

In addition to applying mitigations, the authoring organizations recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK Matrix for Enterprise framework in this advisory. The authoring organizations recommend testing your existing security controls inventory to assess how it performs against the ATT&CK techniques described in this advisory.

To start:

1. Select an ATT&CK technique described in this advisory (see Table 1 to Table 10).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The authoring organizations recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

Resources

Entities requiring additional support for implementing any of the mitigations in this advisory should contact their regional CISA Cybersecurity Advisor for assistance. Key resources organizations should reference include:

• CISA, EPA, NSA, FBI, ASD’s ACSC, Cyber Centre, BSI, NCSC-NL, and NCSC-NZ’s Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators offers best practices to assist organizations in identifying and prioritizing which assets should be secured and protected.
• CISA, FBI, NSA, EPA, DOE, USDA, FDA, MS-ISAC, Cyber Centre, and NCSC-UK’s guidance on Defending OT Operations Against Ongoing Pro-Russia Hacktivist Activity that can help organizations protect OT systems from pro-Russia hacktivist activity.
• NSA and CISA’s guidance on Control System Defense: Know the Opponent helps organizations defend OT and ICS assets against malicious cyber activity.
• CISA and EPA’s resource page on Water and Wastewater Cybersecurity to help organizations reduce risks posed by malicious cyber actors targeting water and wastewater systems.
  • For additional guidance, see CISA, EPA, and FBI’s fact sheet on Top Cyber Actions for Securing Water Systems.
• The Food and Ag-ISAC’s best practices on Food and Ag Cybersecurity: A Guide for Small & Medium Enterprises provides recommendations to help mitigate against cyber threats.
• DOE and National Association of Regulatory Utility Commissioners Cybersecurity Baselines for Electric Distribution Systems and Distributed Energy (DER) webpage provides resources for state public utility commissions and utilities, as well as DER operators and aggregators to help mitigate cybersecurity risks.

Additional resources that apply to this advisory include:

• EPA’s Cybersecurity for the Water Sector resource page provides organizations with guidance on implementing basic cyber hygiene practices.
• CISA’s Cross-Sector Cybersecurity Performance Goals enables critical infrastructure organizations to reduce the likelihood and impact of known risks and adversary techniques.
• CISA’s Require Strong Passwords webpage supports small and medium-sized businesses mitigating against malicious cyber activity that targets weak passwords.
• CISA, NSA, FBI, EPA, TSA, and international partners’ guidance Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.
• DOE’s guidance on Cyber-Informed Engineering recommends considering cyber-enabled risks during the conception, design, and development phases when manufacturing physical systems.
• CISA’s Cyber Hygiene Services help enable critical infrastructure organizations to reduce their exposure to threats by taking a proactive approach to monitoring and mitigating attack vectors.
• CISA, NSA, FBI, and international partners’ guidance on Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software urges software manufacturers to provide customers with products that are safer and more secure.
  • See more information in these Secure by Design Alerts: How Manufacturers Can Protect Customers by Eliminating Default Passwords and How Software Manufacturers Can Shield Web Management Interfaces From Malicious Cyber Activity.

Contact Information

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA, FBI, and/or NSA:

• Contact CISA via CISA’s 24/7 Operations Center at contact@cisa.dhs.gov or 1-844-Say-CISA (1-844-729-2472) or your local FBI field office. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.
• For NSA cybersecurity guidance inquiries, contact CybersecurityReports@nsa.gov.

Australian organizations: Visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents and access alerts and advisories.

Canadian organizations: Report incidents by emailing Cyber Centre at contact@cyber.gc.ca.

New Zealand organizations: Report cyber security incidents to incidents@ncsc.govt.nz or call 04 498 7654.

United Kingdom organizations: Report a significant cyber security incident: report.ncsc.gov.uk (monitored 24 hours) or, for urgent assistance, call 03000 200 973.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. The authoring organizations do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by FBI and co-sealers.

Acknowledgements

Schneider Electric, Nozomi Networks, Eversource Energy, Electricity Information Sharing and Analysis Center, Chevron, BP, and Dragos contributed to this advisory.

Version History

December 09, 2025: Initial version.

Appendix A: Targeting Methodologies for Pro-Russia Hacktivist Groups

For further information on targeting methodologies for pro-Russia hacktivist groups, see:

• CISA’s alert Unsophisticated Cyber Threat Actor(s) Targeting Operational Technology;
• The joint fact sheet Primary Mitigations to Reduce Cyber Threats to Operational Technology; and
• CISA’s Russia Cyber Threat webpage.

Appendix B: Additional Designators Used for Cited Groups

The cybersecurity industry and cyber actor groups often use various names to reference actor groups. While not exhaustive, the following are the most notable names used within the cybersecurity community to reference the groups in this advisory.

Note: Cybersecurity organizations have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the authoring organizations’ understanding for all activity related to these groupings.

• GRU military unit 74455
  • Sandworm Team
  • Voodoo Bear
  • Seashell Blizzard
  • APT44
• Cyber Army of Russia Reborn (CARR)
  • CyberArmy of Russia
  • Народная CyberАрмия (НКА)
  • People’s CyberArmy of Russia (PCA)
  • Russian CyberArmy Team (RCAT)
• NoName057(16)
  • NoName057(16) Spain
  • NoName057(16) Italy
  • NoName057(16) France
• Z-Pentest
  • Z-Pentest Beograd
  • Z-Pentest Alliance
  • Z-Alliance

Introduction

Note: This advisory was originally published on April 7, 2026, to provide tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) related to ongoing cyber exploitation of internet-connected operational technology (OT) devices by Iranian-affiliated advanced persistent threat (APT) actors. The authoring agencies updated this advisory on July 22, 2026, to add new guidance on detecting malicious changes in reusable code modules leveraged within Rockwell Automation PLC programs. It also expands the manufacturer scope to include observed targeting of Schneider Electric, Siemens, and potentially other branded/manufactured PLCs, emphasizing the importance of restricting direct internet access and providing best practice resources for secure deployment.

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Environmental Protection Agency (EPA), Department of Energy (DOE), United States Cyber Command – Cyber National Mission Force (CNMF), and Department of the Treasury (Treasury) (hereafter referred to as the “authoring agencies”) are urgently warning U.S. organizations of ongoing cyber exploitation of internet-connected OT devices—including PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other manufactured PLCs—across multiple U.S. critical infrastructure sectors. As a result of this activity, organizations from multiple U.S. critical infrastructure sectors experienced disruptions through malicious interactions with PLC project files¹ and the manipulation of data displayed on human machine interface (HMI) and supervisory control and data acquisition (SCADA) displays. In a few cases, this activity caused operational disruption and financial loss.

The authoring agencies assess a group of Iranian-affiliated APT actors is conducting this activity to cause disruptive effects within the United States. The group targeted devices spanning multiple U.S. critical infrastructure sectors, including Government Services and Facilities (to include local municipalities), Water and Wastewater Systems (WWS), and Energy Sectors. The authoring agencies previously reported on similar activity targeting PLCs by CyberAv3ngers (aka Shahid Kaveh Group)—a cyber threat actor affiliated with Iran’s Islamic Revolutionary Guard Corps (IRGC) Cyber Electronic Command (CEC).

Due to the widespread use of these PLCs, and the potential for additional targeting of other branded OT devices across critical infrastructure, the authoring agencies recommend U.S. organizations urgently review the TTPs and IOCs in this advisory for indications of current or historical activity on their networks, and apply the recommendations listed in the Mitigations section of this advisory to reduce the risk of compromise.

If owners and operators discover an affected internet-accessible device in their environment, additional technical measures may be necessary to evaluate the risk of compromise. Please engage your cyber incident response plans and contact the authoring agencies and applicable vendors through existing support channels available to customers and integrators (see Contact Information) to receive support, mitigation, and investigation assistance.

For more information on Iranian malicious cyber activity, see CISA’s Iran Threat Overview and Advisories webpage and the FBI’s Iran Threat and Iran Cyber Threat Overview webpages.

Download the PDF version of this report:

(New, July 22, 2026) For a downloadable copy of July 22, 2026 IOCs, see:

• AA26-097A STIX XML (XML, 29 KB)
• AA26-097A STIX JSON (JSON, 30 KB)

For a downloadable copy of historical April 7, 2026 IOCs, see:

Background Information

Similar Historical Activity Targeting Programmable Logic Controllers

During a similar campaign beginning in November 2023, the IRGC CEC-affiliated cyber threat actors known as "CyberAv3ngers” targeted U.S.-based PLCs and HMIs, causing disruptive effects. Private industry and open sources also refer to this group as Hydro Kitten, Storm-0784, APT Iran, Bauxite, Mr. Soul, Soldiers of Solomon, UNC5691, and the Shahid Kaveh Group. These attacks compromised at least 75 devices, targeting U.S.-based Unitronics PLC devices with an HMI used across multiple critical infrastructure sectors, including the WWS. APT actors developed and deployed custom ladder logic code to these devices, replacing the valid ladder logic with malicious code that continues to be observed to date.

For more information on this group’s activity, see the joint Cybersecurity Advisory IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities.

Ongoing Threat Actor Activity Against U.S.-Based Programmable Logic Controllers

The FBI observed Iranian-affiliated APT actors targeting internet-exposed PLCs with the intent to cause disruptions—including maliciously interacting with project files, and manipulating data displayed on HMI and SCADA displays—to U.S. critical infrastructure organizations. Iranian-affiliated APT targeting campaigns against U.S. critical infrastructure have recently escalated, likely in response to hostilities between Iran, and the United States and Israel.

(New, July 22, 2026) At one U.S. victim, the FBI observed the APT actors download a malicious project file to a targeted PLC using configuration software. Analysis indicated the project file retained ladder logic for downstream function but added logic that overrode specific instruction sets responsible for maintaining safe operating parameters in the victim’s environment.

Since at least March 2026, the authoring agencies identified (through engagements with victim organizations) an Iranian-affiliated APT group disrupted the function of PLCs. Organizations across several U.S. critical infrastructure sectors (including Government Services and Facilities, WWS, and Energy Sectors) deployed these PLCs within a wide variety of industrial automation processes. Some of the victims experienced operational disruption and financial loss.

Technical Details

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 19. See the MITRE ATT&CK Tactics and Techniques section of this advisory for tables of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

Initial Access

(Updated, July 22, 2026) The authoring agencies observed Iranian-affiliated APT actors using several foreign-based IP addresses to access internet-facing PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other manufactured PLCs [T0883]. The actors used leased, third-party hosted infrastructure and manufacturers’ PLC programming software to connect to misconfigured victim PLCs. Inbound malicious traffic has been observed targeting PLC devices on the following ports: 44818, 2222, 102, and 502, as well as targeting modems on port 22. Targeted devices include:

• Rockwell Automation: CompactLogix and Micro850 PLCs
• Schneider Electric: BMX P34/Modicon M340 PLCs
• Siemens: S7-1200 series PLCs

Command and Control

(Updated, July 22, 2026) The targeting of ports [T0885] associated with other OT vendors’ protocols suggests these actors are opportunistically targeting devices manufactured by companies other than Rockwell Automation/Allen-Bradley, including Schneider Electric and Siemens. In one reported instance, the actors utilized Dropbear Secure Shell (SSH) software on victim modems to enable them to gain remote access through port 22 [T1219].

Exfiltration

(New, July 22, 2026) The authoring agencies observed Iranian-affiliated APT actors using configuration software—such as Rockwell Automation’s Studio 5000 Logix Designer, Schneider Electric’s EcoStruxure Control Expert, and Siemens’ Totally Integrated Automation (TIA) Portal—on leased, third-party hosted infrastructure to exfiltrate device project files from PLC devices to threat-actor-controlled infrastructure [T1041].

Impact

(Updated, July 22, 2026) After the actors extracted device project files, the FBI and CISA identified the modification and deletion of project file logic, to include Add-On Instructions (AOIs) and data manipulation on HMI and SCADA displays [T1565]. Additionally, the changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators of the anomalies.

Note: An AOI is analogous to a “Function Block” or “User Defined Function Block” used in other PLC vendor programs.

Indicators of Compromise

See Table 1 and Table 2 for recent IP addresses used by the Iranian-affiliated APT actors to communicate with PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, and Siemens in the United States.

Disclaimer: The FBI observed the threat actors using the IP addresses listed below in the specified time frames. This data is being provided for customers to query against logs for indications of historical targeting by the Iranian-affiliated APT actors. The authoring agencies recommend organizations investigate or vet these IP addresses prior to taking action, such as blocking.

MITRE ATT&CK Tactics and Techniques

See Table 3 to Table 6 for all referenced threat actor tactics and techniques in this advisory. The authoring agencies recommend organizations review historical TTPs for similar Iranian-affiliated cyber actor activity in IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Mitigations

The authoring agencies recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of the threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats and TTPs. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

Network Defenders

The cyber threat actors accessed PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other branded/manufactured PLCs to cause disruptions to victim systems. To safeguard against this threat and threats to other types of PLCs, the authoring agencies urge organizations to consider the following mitigations.

(Updated, July 22, 2026) In addition to contacting the authoring agencies, organizations and integrators operating PLCs from the manufacturers mentioned in this advisory should review the previously issued guidance to strengthen the security of their OT deployments:

• Rockwell Automation: Contact the Rockwell Automation Product Security Incident Response Team (PSIRT) at PSIRT@rockwellautomation.com for questions regarding this guidance, or to report cyber incidents related to Rockwell Automation products.
  
  • Refer to Rockwell Automation Security Advisory SD1771 for recommended PLC hardening measures and configuration guidance.
• Schneider Electric: Contact the Schneider Electric Corporate Product Cyber Emergency Response Team (CPCERT) at cpcert@se.com for questions regarding this guidance, or to report cyber incidents related to Schneider Electric products.
  
  • Refer to Schneider Electric’s Recommended Cybersecurity Best Practices and Cybersecurity User Guide for Modicon Controller Platform for guidance on securing and configuring PLCs.
• Siemens: Contact Siemens ProductCERT at productcert@siemens.com for questions regarding this guidance, or to report cyber incidents and vulnerabilities related to Siemens products.
  
  • Refer to Siemens Security Bulletin 104599 for a list of security measures to harden PLCs and in-depth configuration guides.
  • Siemens users should review the Cybersecurity for Industry Operational Guidelines and implement defense-in-depth controls within their automation systems.

Immediate steps to prevent the attack:

• Disconnect the PLC from the public-facing internet [CPG 3.S]. Follow the joint guidance Secure connectivity principles for OT to safely allow remote access. Specifically, “remove inbound port exposure,” so the OT system is never directly exposed to the internet or external networks, and to ensure all access is mediated, monitored, and controlled. Do this through a secure gateway (jump host) that brokers the connection.
  
  • Ensure cellular modems, used for remote field connectivity and access, are secured with strong authentication and updated.
  • Enable logs for connected modems and regularly review for suspicious activity to detect intrusions and improve incident response speed.
  • (New, July 22, 2026) To mitigate unauthorized access to OT via cellular modems, organizations should consider implementing isolated architectures, such as private Access Point Name (APN), 5G Public Network Integrated Non-Public Network (PNI-NPN), cellular Software-Defined Wide Area Network (SD-WAN), Zero Trust Network Access (ZTNA), or a site-to-site virtual private network (VPN).
• (New, July 22, 2026) Strictly control network access to PLC devices.
  
  • Configure firewall rules or access control list (ACL) security features on PLCs or programmable controllers to allow only authorized communications between expected control system devices. Block access from unauthorized or threat actor-controlled IP addresses, such as those associated with hosting providers.
• For controllers with a physical mode switch, place the physical mode switch into run position to prevent remote modification. Devices should only be in the program or remote position when updating or downloading software online and immediately switched back to the run position when complete. (See Rockwell Automation’s² System Security Design Guidelines for manufacturer’s instructions.)
  
  • (New, July 22, 2026) Prior to switching the device to run mode, review and validate project files, as changing modes will lock in the current project file downloaded to the device.
• For devices that allow software key switching, enable programming protection in PLC configuration software (S7 TIA Portal) to limit who can modify PLCs remotely. (See Siemens’ Cybersecurity for Industry Operational Guidelines for the manufacturer’s instructions.)

Follow-up steps to strengthen security posture:

• (New, July 22, 2026) Review project files running on PLCs for unauthorized changes. Use vendor-provided integrity checking tools and visually compare the running program to known good logic. Ensure reusable logic and input/output configurations are valid. For Rockwell Automation PLCs listed in the Customer Guidance to Disconnect Devices from the Internet, check the AOIs for any anomalous modifications.
  
  • If restoring from backups, verify the backup does not contain malicious logic before deployment.
  • Review logs and configurations on all connected devices, including modems, HMIs, and workstations, to assess potential lateral movement by threat actors. If it appears the actors connected to additional devices, reimage these devices to remove any potential malicious changes or access tools.
• (New, July 22, 2026) Ensure device passwords are changed from their default and are configured to use complex, unique combinations of letters, numbers, and symbols that are not easily guessable. Implementing robust password practices remains a critical security measure that can help prevent unauthorized access and strengthen the overall security posture of OT devices.
• (New, July 22, 2026) Take defensive measures to minimize the risk of exploitation. Conduct comprehensive impact analysis and risk assessments prior to deploying defensive measures.
• Create and test strong backups of the logic and configurations of PLCs. Store backup files offline and secure the physical removal media to enable fast recovery.
• Implement multifactor authentication (MFA) [CPG 3.F] for access to the OT network from an external network.
• If remote access is required, implement a network proxy, gateway, firewall, and/or VPN in front of the PLC to control network access.
  
  • A VPN or gateway device can enable MFA for remote access even if the PLC does not support MFA. Implement security rules on these higher-level network security mechanisms to prevent the type of repeated and sustained login attempts seen during a brute force attack. When possible, implement a device control list for workstations sending messages or connecting to OT components.
  • Use the device control list to monitor for logon activity for unexpected or unusual access to devices from the internet.
• Keep PLC devices updated with the latest software patches issued by the manufacturer. Use established downtime windows to install patches. Known Exploited Vulnerabilities may need to be prioritized outside a downtime window.
• Configure external and internal firewalls to block traffic using common ports associated with network protocols that are unnecessary for the particular network segment.
• Disable any unused authentication methods, logic, or features, such as default authentication keys and passwords, as well as unused or needed services such as Teletype Network (Telnet), File Transfer Protocol (FTP), Remote Desktop Protocol (RDP), Virtual Network Computing (VNC), and web services.
• Monitor asset management systems for device configuration changes, which can be used to understand expected parameter settings.
• Monitor the content of network traffic for the following:
  
  • Unusual logins to internet-connected devices or unexpected protocols to/from the internet. 
  • Functions of industrial control systems management protocols that change an asset’s operating mode or modify programs.
• (New, July 22, 2026) Ensure service providers are informed of active threats targeting internet-connected PLC devices. Owners and operators should communicate directly with service providers to address risks, especially when remote monitoring or maintenance is involved. Some service providers may rely on internet connectivity essential to monitor and maintain OT/ICS operations but may not be fully aware of active threats.

In addition, the authoring agencies recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques, as well as reduce the impact and risk of compromise by cyber threat actors:

• Reduce risk exposure. CISA offers a range of services at no cost, including scanning and testing, to help organizations reduce exposure to threats via mitigating attack vectors. CISA’s Cyber Hygiene Services can help provide additional review of organizations’ internet-accessible assets. 

Device Manufacturers

Note: The following guidance is general in nature and not specific to any OT vendor. Some of the features, settings, and practices may already be offered by certain vendors. The inclusion of this guidance should not be interpreted as an assertion that vendors referenced do not offer such security features. Also, this advisory is not highlighting a new vulnerability in the identified products, but instead discusses opportunistic targeting. Device manufacturers can make opportunistic attacks more difficult at scale by encouraging more secure behavior by default and in operations, as discussed below. 

Although critical infrastructure organizations using PLC devices can take steps to mitigate the risks, it is ultimately the responsibility of the device manufacturer to build products secured by design and default. The authoring agencies urge device manufacturers to take ownership of their customers’ security outcomes by following the principles in the joint guide Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products, primarily:

• Change the manufacturers’ default settings to prevent exposing administrative interfaces to the internet.
• Do not charge additional fees for basic security features needed to operate the product securely.
• Support MFA, including via phishing-resistant methods.

By using secure by design tactics, software manufacturers can make product lines secure “out of the box” without requiring customers to spend additional resources making configuration changes, purchasing tiered security software and logs, monitoring, and making routine updates.

For more information on common misconfigurations and guidance on reducing their prevalence, see joint advisory NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations. For more information on secure by design, see CISA’s Secure by Design webpage and joint guide.

Validate Security Controls

In addition to applying mitigations, the authoring agencies recommend exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The authoring agencies recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 3 to Table 6).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The authoring agencies recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the ATT&CK techniques identified in this advisory.

Resources

• Authoring Agencies: IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities
• CISA: Bulletproof Defense: Mitigating Risks From Bulletproof Hosting Providers
• EPA: Cybersecurity for the Water Sector
• CISA: Water and Wastewater Cybersecurity
• CISA: Exploitation of Unitronics PLCs used in Water and Wastewater Systems
• CISA: Iran Threat Overview and Advisories
• FBI: The Iran Threat and Cyber Threat Overview: Iran
• CISA, MITRE: Best Practices for MITRE ATT&CK Mapping
• CISA: Decider Tool
• CISA: Cross-Sector Cybersecurity Performance Goals 2.0
• CISA: No-Cost Cybersecurity Services and Tools
• CISA: Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products
• NSA, CISA: NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations
• CISA: Secure by Design
• FBI, CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• United Kingdom National Cyber Security Centre: Secure connectivity principles for operational technology

Contact Information

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA, the FBI, and/or NSA:

• Contact CISA via CISA’s 24/7 Operations Center at contact@cisa.dhs.gov or 1-844-Say-CISA (1-844-729-2472). File a claim with FBI’s Internet Crime Complaint Center (IC3) or contact your local FBI field office. When available, please include the following information regarding the incident: 
  • Date, time, and location of the incident;
  • Type of activity;
  • Number of people affected;
  • Type of equipment used for the activity; and
  • Name of the submitting company or organization, and a designated point of contact.
• For NSA cybersecurity guidance inquiries, contact CybersecurityReports@nsa.gov.
• Entities required to report incidents to DOE should follow established reporting requirements, as appropriate. For other energy sector inquiries, contact EnergySRMA@hq.doe.gov.
• Contact the Rockwell Automation PSIRT for questions regarding their guidance or for reporting cyber incidents related to Rockwell Automation products at PSIRT@rockwellautomation.com.
• Contact the Schneider Electric CPCERT at cpcert@se.com for questions regarding this guidance, or to report cyber incidents related to Schneider Electric products.
• Contact Siemens ProductCERT for up-to-date information about the security of Siemens products or to report cybersecurity vulnerabilities at productcert@siemens.com. For support with increasing the security of installed Siemens PLCs, contact Siemens Industrial Cybersecurity Services at services.automation@siemens.com. See Siemens ProductCERT and Siemens CERT for more information.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. CISA and the authoring agencies do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA and the authoring agencies.

Version History

April 7, 2026: Initial version.

July 22, 2026: Update includes new guidance on detecting malicious activity, expanded scope of observed targeting, and best practices for secure PLCs deployment.

Notes

¹Project file refers to the software file that contains ladder logic and configuration settings. On Rockwell Automation devices, it is referred to as an .ACD file.

² See CompactLogix 5370 Controllers (Chapter 5: “Select the Operating Mode of the Controller”) for more information on functions available for the switch.

Paper.

VentureBeat Research measured the five controls an enterprise has to build before it can trust an agent: identity, evaluation, cost telemetry, the context layer, and orchestration. Identity governs which agent is allowed to do what, under whose credentials. Evaluation determines whether the agent's work is any good. Cost telemetry tracks what each agent costs to run. The context layer supplies the business data and definitions agents draw on when they answer. And the orchestration control plane coordinates multi-step agent work. Each of our five reports measures one of those controls.

Most deployed "agents" are chatbots wearing the label. Seventy-one percent of enterprises said a quarter or fewer of their deployed "agents" can complete multi-step work on their own; only 10% said true agents are the majority of what they run. These respondents are positioned to know: 81% recommend or decide AI purchases at their companies. A single-prompt chatbot with a human reading every answer needs none of the controls the other four reports measure. A true multi-step agent needs all of them — and most enterprises can't say which one they've deployed. (Full findings: Agentic Orchestration report.)

Autonomy is outrunning trust in the evaluations that gate it. Two-thirds of enterprises either already allow an agent to push a code or system change to production on automated evaluation results alone, with no human review, or are actively engineering toward that within 12 months. Only 5% fully trust the evaluations that would make that call — and half of enterprises shipped an agent that passed internal evaluations and then caused a customer-facing failure in the past year. Before removing human review from any workflow, test evaluations against production outcomes rather than internal benchmarks. (Full findings: Agent Reliability & Evals report.)

Companies that let agents share credentials get hit more often. Sixty-nine percent of companies let at least some of their agents share credentials — multiple agents operating under one API key or service account. Organizations that allow credential sharing anywhere experienced a security incident or near-miss at a 63.5% rate (47 of 74), against 40.9% (nine of 22) at companies where every agent has its own scoped identity. The fix is scoped identity for every agent, starting with the ones that touch production systems. (Full findings: Agentic Security & Identity report.)

The most expensive hardware in the building runs at half capacity or less. More than eight in 10 enterprises that run their own GPUs reported utilization of 50% or less, and only 44% rigorously track what their AI compute actually costs and returns. The number worth chasing first isn't more GPUs — it's the utilization and per-workload cost of the ones already running. (Full findings: AI Infrastructure & Compute report.)

Agents answer confidently from data nobody governs. Fifty-seven percent of enterprises traced a confident, wrong agent answer in the past six months to their own missing or inconsistent business context — wrong metrics, stale definitions, absent documents — and most saw it happen more than once. Governing the definitions agents answer from — metrics and entities first — has to come before scaling the agents that depend on them. (Full findings: Context Layers / RAG report.)

No layer has an entrenched incumbent: The defaults today are the built-in tools that ship with the big AI platforms enterprises already use. Switching intent runs highest in orchestration itself, where 68% plan to adopt, add, or replace platforms within 12 months and 34% within the quarter. Our surveys did not ask which direction that money moves — toward the platforms' built-in tools or toward the specialists challenging them — and that open question is the next four quarters of this market.

About this research

VentureBeat Research fielded five parallel surveys in June 2026 under its VB Pulse program: Agentic Orchestration (101 respondents), Agent Reliability & Evals (157), Agentic Security & Identity (107), AI Infrastructure & Compute (107), and Context Layers / RAG (101) — 573 qualified respondents in total, all at organizations with 100 or more employees. Samples are self-selected, and some findings should be read directionally; each report carries its full methodology note. What the pattern supports more strongly than any single percentage is the direction: every survey, independently, points the same way. VentureBeat produces both this research and VB Transform, the conference where these reports debuted.

The Cyber Express Weekly Roundup 

U.S. Accounts for Nearly Half of Global Ransomware Attacks in H1 2026 

Dubai Police Warns Against Online Visa Fraud Schemes 

Craneware Data Breach Exposes Employee and Customer Information 

U.S. Targets Illegal FIFA World Cup Streaming Networks 

Chick-fil-A Customer Accounts Targeted in Credential Attack 

South Korea Diplomatic System Breach Lasted Nearly 10 Months 

Weekly Cybersecurity Takeaway 

Google Fined Over Self-preferencing on Google Search

Google Play Restrictions Lead to Second Fine

Digital Markets Act Enforcement Brings Compliance Deadline

Commission Investigations Began in 2024

Zimbra Phishing Campaign Uses CVE-2025-66376

LAUNDRY BEAR Targets Email and Sensitive Data

Ulej and Flowerbed Support Email Data Exfiltration

Organizations Urged to Patch Vulnerable Zimbra Systems

The Freiburg, Germany-based AI lab says FLUX 3 is jointly trained across those modalities rather than assembling separate image, video and audio models behind a common interface.

That distinction is central to the company's pitch: BFL wants enterprises to think about creative generation, simulation, computer use and robotics as connected applications of a single capability it calls visual intelligence — models, in the company's words, "that can perceive, predict, and act across physical and digital environments." This release marks BFL's first public video generation model.

FLUX 3 will be offered through four product lines: FLUX 3 Video, FLUX 3 Image, FLUX 3 Action and the upcoming, open source FLUX 3 Dev. FLUX 3 Video, with optional native audio generation, and FLUX 3 Action are entering a gated "Early Access" program now, to which anyone can apply, but which BFL must approve.

There is presently no public access through BFL's application programming interface (API) or those of partners yet, but the company says FLUX 3 Image will roll out in the coming weeks, followed by general availability. The limited initial availability rollout echoes the release strategies of new models from other frontier labs in the U.S. lately, including Anthropic and OpenAI, though those were ostensibly for security concerns and due to government request.

What the company has not announced is pricing, production service-level commitments, evaluation methodology, sample sizes, rater counts or any image-model benchmarks at all. Enterprise buyers therefore cannot yet calculate total cost of ownership or independently reproduce the video comparisons.

Another big notable omission: FLUX 3 is not launching with downloadable weights at this time, nor an open source license. BFL says faster and open-weight versions will arrive later this year, and its technical blog names FLUX 3 Dev as "open-weight access to a multimodal backbone, for content creation (video, audio and image) and action prediction" — a considerably broader commitment than any previous FLUX Dev release, all of which covered images only.

But it arrives last in the sequence. Developers accustomed to receiving a locally deployable FLUX variant alongside — or soon after — a major model announcement will have to wait. That delay does not negate the company's commitment, but it is disappointing given the role open weights have played in FLUX's adoption thus far.

Flux 3 is rated higher than the competition, but missing pricing and benchmarking details may prevent rapid enterprise adoption

BFL has published several benchmark comparisons, but they're qualified as preliminary — with full benchmark results and methodology to be published later during broader general availability.

In early head-to-head preference testing on 10-second, 720p text-to-video clips with audio, the company says FLUX 3 was preferred over Luma Ray 3.2 in 93% of comparisons, Runway Gen-4.5 in 77%, Grok Imagine Video in 69%, Kling v3 Pro in 60%, Happy Horse v1 in 59%, Happy Horse 1.1 in 57%, and both Seedance 2.0 and Google's Gemini Omni Flash in 52%.

One caveat travels with every one of those figures, and it comes from BFL itself. The chart carrying the results is labeled a "preliminary evaluation of an early FLUX 3 candidate" — meaning the numbers describe a pre-release checkpoint rather than the model now entering early access. That cuts both ways: the shipping model may perform better, but nothing published today measures what customers will actually call.

Luma Ray 3.2 and Runway Gen-4.5, where FLUX 3 posted 93% and 77%, are the softest comparisons on the list — established products, but not the models currently setting the pace in independent video rankings. Those are real wins, and they are the ones least likely to change an enterprise shortlist.

Seedance 2.0, at 52%, is a statistical coin flip against a model most Western enterprises cannot currently procure. ByteDance indefinitely postponed Seedance 2.0's international rollout after Netflix, Warner Bros., Disney, Paramount and Sony sent legal threats over alleged systematic copyright infringement, and that suspension remains in place. Tying a frozen product is neither a strong claim nor a damaging one.

Gemini Omni Flash, also at 52%, matters much more. Omni is the closest large-platform analogue to what FLUX 3 is attempting — multimodal input, video and audio-aware creation, conversational editing — and by BFL's own measurement, the two are indistinguishable on 10-second text-to-video quality.

Google's advantage in that matchup is that Omni is generally available via Google's Gemini API for $0.10 per second of generated 720p video, or a 10-second clip for around.

One regional wrinkle matters for a German company's home market. Editing uploaded video is unavailable to Omni Flash users in the European Economic Area, Switzerland and the United Kingdom, though editing video the model itself generated is permitted. A European enterprise that wants to run its existing footage through a generative editing pass cannot currently do so on Omni Flash.

Here's a rough guide for enterprises considering which video models to rely upon:

One architecture for media generation and physical action

FLUX 3 builds on Self-Flow, BFL's method for aligning multimodal understanding and generation within one architecture, publicized back in March 2026.

The company says it significantly scaled up compute and data to train across video, images and audio simultaneously, and that testing showed video generation and action prediction do not require separate foundations — the same architecture could be extended to action prediction without sacrificing what it learned from video.

"We place vision at the center of our approach because it is the most signal-rich medium of the physical world. Images convey structure, images and video teach spatial relationships, video teaches dynamics, and actions reveal causal relationships. But vision alone is not the complete picture," said Robin Rombach, co-founder and CEO of BFL, in a pre-release statement provided to VentureBeat. "True intelligence means perceiving the world: predicting how it will change, taking action, and learning from the results. Joint training within one unified architecture is what will get us there, because each training modality strengthens the others. Audio conveys timing, prosody, and physical events that elude vision. Language conveys goals, abstractions, and instructions that pixels cannot easily express."

He put the case more bluntly elsewhere in the announcement: "You can't cheat reality. A model that only learns images can only generate images. But the world is not made of still frames. It moves, sounds, changes, and responds."

BFL says FLUX 3 targets creative tooling, media, design, e-commerce and physical AI, supporting video generation with synchronized audio, precise image editing, product and material consistency across motion, multilingual generation and robotic action prediction. It is already being tested by Canva, Burda, Magnific (formerly Freepik), Krea and Picsart.

For creative software companies, the appeal is consolidation. A single foundation could potentially support storyboarding, image editing, product rendering, video variation and localization without repeatedly translating assets and instructions between disconnected models.

For robotics teams, the potential value is data efficiency. Models that already encode motion, object behavior and physical change may need less task-specific robot training than systems starting from raw demonstrations.

What FLUX 3 Video can actually do

The video tier is the most concretely specified part of the launch, and it settles a question that had been circulating as rumor: FLUX 3 generates clips of up to 20 seconds with audio in a single generation.

Every video output comes with native audio. For comparison, HappyHorse 1.0 tops out at 15 seconds of 1080p with synchronized audio — though BFL has not stated what resolution its 20-second clips run at, and its published evaluations were conducted at 720p. Still, a 20-second long clip from a single prompt is among the longest yet achieved, matching OpenAI's discontinued Sora model.

The capability list BFL published covers:

• Text-to-video generation.

• Image-to-video generation, either animating from a starting frame or using images as visual references.

• Video-to-video generation from a reference clip, carrying elements such as a specific character into a new scene or context.

• Generative video-audio continuation from existing video and audio input.

• Keyframe-to-video generation for controlled transitions between defined moments.

• Multilingual dialogue.

• A broad range of visual styles and aspect ratios, from candid camcorder footage to animation and cinematics.

• Typography generation and animated design.

• Agentic chaining of individual clips into longer, multi-shot sequences.

That last item is the one enterprise video teams should look at hardest. BFL claims the capabilities combine to produce sequences lasting several minutes, with visual references keeping characters consistent across scenes. If that holds up under production conditions, it addresses the constraint that has kept generative video out of most commercial pipelines: not clip quality, but continuity across shots.

It is also the capability where competition is most direct. HappyHorse 1.1's headline upgrade is R2V, or Reference-to-Video, which accepts multiple character reference images to hold identity stable across generated footage — the same problem, approached at the input layer rather than through agentic clip chaining. Alibaba also claims zero-drift lip sync and has specifically targeted the artifacts that mark commercial AI video as synthetic, including facial oiliness and over-sharpening. Character consistency is where this category is being contested, and both companies know it.

BFL says FLUX 3 Video is already particularly strong at human facial expressions, associating sounds with physical events, and multilingual output. On the image side, the company says preliminary evaluations conducted during midtraining show significant improvement over earlier FLUX versions in complex prompt handling and text generation, including high-accuracy text in multiple languages. It published no image benchmarks or win rates.

FLUX-mimic tests whether video models can become robot models

BFL is applying its unified-architecture thesis through FLUX-mimic, a video-action model built on FLUX 3 and developed with Swiss firm Mimic Robotics, one of the first partners to receive early access.

The technical blog describes two distinct routes to action prediction: integrating native action prediction directly into FLUX 3, scaling up the initial Self-Flow work; and using the pretrained video backbone as a dynamics-aware foundation from which specialized action models can be finetuned with limited task-specific data. FLUX-mimic is the second route — the FLUX 3 backbone combined with mimic's robot-learning and production-deployment expertise in dexterous manipulation.

FLUX-mimic is designed for general-purpose robotic manipulation: helping robots understand a visual scene, predict the consequences of an action, and adapt to new tasks with far less task-specific data.

BFL and Mimic Robotics say that depending on task difficulty, the model can be finetuned for a specific manipulation task with as little as 30 minutes of robot data, where prior approaches have required 30 or more hours.

"The hardest part of robotics is data," said Elvis Nava, CTO of Mimic Robotics, in a statement provided to VentureBeat. "Every new task normally means hours of a robot repeating itself. Because FLUX-mimic is built on top of frontier video models that already understand how the physical world behaves, it picks up a new task in minutes, not days. This way, we can leapfrog the current state of the art in robot learning."

BFL argues that a model trained only on images cannot understand a world that "moves, sounds, changes, and responds," and that physical understanding is what produces convincing generated footage. Google makes a nearly identical claim for Gemini Omni.

Its developer documentation cites "world knowledge" that combines "an understanding of physics" with Gemini's grasp of history, science and cultural context. Its marketing is blunter still: "Most AI models just predict the next pixel to build a narrative or an image. Gemini Omni is different," the company posted in June, crediting the model with "an intuitive understanding of forces like gravity, kinetic energy, and fluid dynamics for more realistic movements that follow real-world logic."

The practical consequence for enterprise buyers is that world-model language is not a differentiator. Two of the three leading video systems now market physical understanding as their central advantage, and neither has published a benchmark that measures it.

There is no standard test for whether generated water behaves like water, whether a dropped object falls at a plausible rate, or whether a sound arrives when the impact does. Human preference ratings capture some of it indirectly. Nothing else on offer captures it at all.

Open weights helped make FLUX an industry standard

BFL officially launched in summer 2024 and gained a name for itself in the AI industry in the intervening two years for its commitment to open sourcing high-quality AI image models beloved by developers, creatives, and enterprises.

The company's founders, including Rombach, Andreas Blattmann and Patrick Esser, previously helped create VQGAN, latent diffusion and Stable Diffusion, the latter the open source technology that kicked off broad AI generation capabilities for the masses and currently used by many AI image generators and companies.

That reach translated into commercial distribution. FLUX models now power generative features inside Adobe Photoshop, Picsart and Nous Research's Hermes Agent, among other platforms, and the company cites film director Martin Scorsese among professional users.

Wired magazine described Black Forest Labs as a relatively small company that nevertheless became a leading competitor to Silicon Valley's largest AI labs, with FLUX models ranking near the top of image benchmarks and becoming some of the most downloaded text-to-image models on AI code sharing community Hugging Face. The company says it now runs a 100-person team across Freiburg and San Francisco.

FLUX.1 Dev, FLUX.1 Kontext Dev, FLUX.1 Fill Dev and related control models, released shortly after the firm's launch, gave researchers and creative-tool developers access to downloadable checkpoints, local inference and integrations with frameworks including Hugging Face Diffusers and ComfyUI. FLUX.1 Kontext Dev, for example, was released as an open-weight model for research and noncommercial use, with generated outputs permitted for commercial purposes under the applicable license.

The company continued that pattern with FLUX.2 Dev in late 2025, a 32-billion-parameter open-weight model combining generation and multi-reference editing. Black Forest Labs called it the strongest open-weight image generation and editing model available at launch and released weights, reference inference code and optimized implementations for consumer Nvidia GPUs.

FLUX 3 Dev raises the stakes on that evaluation. Previous Dev releases were image models. This one is described as a multimodal backbone spanning video, audio, image and action prediction — meaning a single license will govern whether a company can locally deploy a model that touches both content production and physical machinery. BFL hasn't yet shared information about its license, the parameter count, quantizations or hardware requirements.

The company frames open weights as an enterprise feature rather than a community gesture, arguing they enable secure, low-latency local deployment for applications like robotic control systems and let teams adapt FLUX 3 to their own data, products and workflows.

The financial backing behind FLUX 3 is worth noting alongside the technical claims. Black Forest Labs is valued at $3.25 billion and has raised more than $450 million from investors including a16z, AMP, Salesforce Ventures, Nvidia, General Catalyst, Adobe Ventures, Figma Ventures, Canva and Deutsche Telekom's T.Capital.

Summary

Successful exploitation of this vulnerability could allow an authenticated attacker to write arbitrary files to restricted system directories outside of the application's intended directory.

The following versions of Rockwell Automation ThinManager are affected:

• ThinManager >=13.0.0|<13.0.7, >=13.1.0|<13.1.5, >=13.2.0|<13.2.4, >=14.0.0|<14.0.2

Background

• Critical Infrastructure Sectors: Chemical, Critical Manufacturing, Energy, Food and Agriculture, Water and Wastewater
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow an attacker with network access to achieve remote code execution.

The following versions of Johnson Controls C-CURE 9000 and Victor application server are affected:

• C-CURE 9000 and victor <=v2.90_v3.0 
• victor Web <=v7.1 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Ireland

Vulnerabilities

Acknowledgments

• Harrison Neal reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could result in an attacker obtaining confidential information from the device.

The following versions of Johnson Controls XAAP Android are affected:

• XAAP Android <1.53

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Ireland

Vulnerabilities

Acknowledgments

• Johnson Controls reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow an unauthenticated network-adjacent attacker to crash critical IEC 61850 services or execute arbitrary code, disrupting or compromising protection, visibility, and control functions.

The following versions of MZ Automation libIEC61850 are affected:

• libIEC61850 >=v1.0.0|<=v1.6.1 

Background

• Critical Infrastructure Sectors: Critical Manufacturing, Energy, Transportation Systems
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Abhinav Agarwal reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could cause the parsing process to crash, which will cause a denial of service.

The following versions of MZ Automation lib60870 are affected:

• lib60870 <=2.4.0

Background

• Critical Infrastructure Sectors: Chemical, Energy, Water and Wastewater
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Lars Tray reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this (these) vulnerability(ies).

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow an attacker with access to the IT network to manipulate industrial control devices without requiring physical access, specialized insider knowledge, or advanced tooling.

The following versions of Panduit IntraVUE are affected:

• IntraVUE <=3.2.1a14 

Background

• Critical Infrastructure Sectors: Critical Manufacturing, Energy, Information Technology, Water and Wastewater
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Netherlands

Vulnerabilities

Acknowledgments

• Phlebas of Lumintel reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the Internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow a non-privileged user to escalate privileges or view the credentials of other users.

The following versions of Weintek cMT3092X are affected:

• cMT3092X firmware <20210218 
• EasyWeb <v2.1.20

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Taiwan

Vulnerabilities

Acknowledgments

• Vincenzo Giuseppe Colacino of Secoore reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take the following measures to protect themselves from social engineering attacks:

Practice principles of least privilege.

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

“Our founder and CTO has actually been really pushing to enable our agents in YOLO mode,” Rishi told the audience. That admission comes from a publicly traded data security firm whose business is backing up what he called the most important data in the world.

YOLO mode strips the permission prompt out of agent workflows and lets the agent act on its own. In Rubrik's version, a second AI judges every action in real time against policy in place of a human clicking approve. Rubrik is running the experiment on itself first. Rishi treats autonomy as a settled capability question and an open judgment question. "If you ask the agent to act autonomously, it will," he said. "It's a question that you have internally. Should it?"

Rubrik earned that question the hard way. When Claude Code and Cowork pilots rolled out, the company required every command to run in ask mode so the employee issuing it carried the liability, and the developer pushback filled a single Slack thread 120 messages deep.

"The developers basically are pushing back, and they're like, this is like the iTunes service agreement. I'm just hitting check, check, check, check, check, check, check," Rishi said. "There's no way that I can actually read through this. And it becomes security theater." Roughly 80% of respondents are in the same bind, Rishi said, citing Rubrik Zero Labs research that found monitoring and approving agent actions takes more time than the agents save. The State of the Agent, the April report behind that figure, surveyed more than 1,600 IT and security leaders.

SAGE is the reason Rubrik trusts the bet. Short for Semantic AI Governance Engine, SAGE is the arbitration layer inside Rubrik Agent Cloud that watches every action an agent takes and reads the semantic intent behind it, then rules the action in or out against policies written in natural language. "We took what people said was human in the loop, a good idea, and we replaced it with AI in the loop," Rishi said, describing the pitch to security chiefs he characterized as skittish about non-deterministic systems.

Security approval, not cost, blocks AI ROI

Rishi’s path to Rubrik ran through Predibase, the generative AI infrastructure startup he co-founded and ran as CEO until Rubrik agreed to acquire it in June 2025. Before that, he led ML product at Google on the team that became Vertex AI, served as Kaggle's first product manager as it grew from about one million to ten million users, and holds bachelor's and master's degrees in computer science from Harvard.

Over roughly his first three and a half months at Rubrik, Rishi set up 200 customer conversations with IT and security leaders across a customer base that looks like the Global 2000, asking open-ended questions about cost, latency, performance, and orchestration. "Pretty consistently, what I heard through all of those conversations was that all of those are pretty secondary," he said. "The main challenge is actually, how do I get this approved from a security and risk standpoint? I'm concerned about all the different things that could go wrong. Actually, I felt like that was one of the biggest things constraining ROI."

VentureBeat Pulse research presented on the Transform stage earlier in the day confirms the gap Rishi kept hearing. Two-thirds of enterprises, 66%, already allow or are actively building toward production deployment with zero human review, yet only 5% fully trust the automated evaluations that would make that decision.

One AI reading what the rulebook can't

Rubrik's own policies exposed why written rules fail as enforcement. One internal rule states that agents should respect Rubrik's customer data use policy, which sounds enforceable until someone tries. "Rubrik's customer data use policy is like a three-page document of legal text," Rishi said. "I have no idea how to write that in there as a rule." Asked on stage how a team of AI infrastructure people took on a problem that security engineers own, Rishi answered, "with a lot of naivety and innocence, honestly." His team bet that models good at understanding language could police other models, and SAGE became the answer.

The case for putting a model in the judgment seat comes down to precision. A rule like "agents should not be able to edit revenue fields in Salesforce" fails in conventional tooling because Salesforce does not delineate which fields count as revenue, Rishi explained, so administrators fall back on approving every Salesforce action by hand. SAGE reads the intent instead and acts as a judge, carrying organizational context, which can tell a benign lookup from the edit the policy prohibits.

Keeping the judge small is what makes the economics work. SAGE runs on a small language model that Rishi said operates at an order of magnitude lower cost and latency than a frontier LLM. "If I told you, don't worry, you're gonna be secure and governed, but I'm gonna double your cost and latency, you would tell me to get out of the room," Rishi said.

When Rishi asked who in the audience had worried about token consumption over the past year, half the hands went up. "And I guess the other half is probably just too lazy to raise their hand," he said.

SAGE is an aggregation of judges based on parameter-efficient fine-tuning that Rubrik uses to take on task-specific variants of a base model with shared organizational context. One judge watches for tool-use hallucinations while another suppresses PII before it can leave, each running as its own enforceable policy. Security and GRC teams have started writing financial rules into the same layer, including one internal policy barring AI spend on personal projects.

The lethal trifecta

Asked which attacks worry him most, Rishi pointed at the lethal trifecta, the term security researcher Simon Willison coined in June 2025 for an agent that holds private data while taking in content nobody vetted, with a channel to send what it finds to the outside world. The danger, according to Rishi, is what happens when individually legitimate permissions stack. An agent granted Salesforce access and email access on an employee's credentials has done nothing wrong yet, with yet being the operative word. "A very simple example is that an agent can start pulling data from Salesforce and then decide to accidentally leak and exfiltrate that out via an email," he told the audience. A financial services company he met the morning of the session made the point for him, telling Rishi that none of the individual permissions are bad on their own and the agent needs every one of them to do its job. "It should have permission to each of those systems, but it's the combination that ends up becoming really destructive," Rishi said.

Traditional identity and access management never priced in that combination because it relied on the judgment of the employee holding the credentials, Rishi argued, and agents supply none. "I can tell you the number of times Claude Code has tried to leak some of our sensitive source code to a public GitHub repository is incredibly high," he said. Cutting agents off from public resources entirely would defeat their purpose, which returns the problem to adjudicating intent in context rather than revoking access.

A separate VentureBeat June Pulse survey of 107 qualified enterprise respondents maps the blast radius of exactly this pattern. On the Transform stage that morning, VentureBeat research reported that 69% of companies run credential sharing somewhere in their agent fleet. Companies with shared credentials anywhere got hit more often, reporting a security incident or near-miss at a 63.5% rate (47 of 74), against 40.9% (9 of 22) where every agent carries its own scoped identity.

The attacks no single turn reveals

Rubrik Agent Cloud reached general availability in February, though not everything Rishi described ships in it yet. Backtesting is just starting to roll out. The feature replays an organization's historical agent actions and tool calls against a new policy, showing where the policy would have stepped in and where an action would have sailed through uncaught, with policy edits applied in real time. Rishi called that archive one of the most valuable data troves an enterprise holds.

Real-time detection and blocking turn out to be the entry point rather than the whole product. Some attacks never trip a single-action rule. "No individual turn of the conversation was problematic, but if you took the session as a full trace, that ended up being problematic," Rishi said. Agent Cloud runs batch analysis across entire session traces every hour or every day and surfaces what Rubrik calls insights, the problems no individual guardrail caught. The same Zero Labs report found that 88% say they lack the ability to roll back agent actions without system disruption, a recovery gap that sits squarely in Rubrik's original line of business.

A skeptical CISO will ask the question the fireside did not answer. SAGE is a non-deterministic model policing other non-deterministic models, and Rishi offered no false positive or false negative rate for the judge itself. The closest thing the architecture gives to an answer is auditability, since backtesting and the batch insights both leave a human-reviewable trail of each call SAGE made and whatever got past it. Who watches the watcher, for now, is a trail of receipts rather than a benchmark. Until that benchmark exists, AI in the loop stays an operational wager rather than a quantified control.

Three questions fall out of the session for security teams. How many of the guardrails now in production depend on a human clicking approve, and what happens to that workload as agent count grows? Does anything in the stack enforce semantic intent, or is it all allow and deny lists? And can the team backtest agent behavior against a new policy, then unwind a multi-turn session without taking systems down?

Rishi's timing has a market behind it. In the same VentureBeat research, 82% of enterprises still name their primary AI provider's built-in guardrails and cloud controls as their main agent security layer, and 59% plan to adopt, add, or replace agent security tooling within the next 12 months. Only 12% include an agent-identity product in what they are considering, even with credential sharing still the norm. Every CISO at that Anthropic roundtable had a policy document and no enforcement mechanism, and Rubrik built a product for the space between the two. YOLO mode is the bet that an AI watching other AIs can finally make the policies real.

This wave of VentureBeat Pulse Research examines enterprise agent orchestration: which platforms enterprises run on, what drives the choice, what they optimize for, how they expect agent control to be structured, and — most revealingly — how orchestrated their deployed “agents” actually are and how tightly they control the cost of running them.

The central finding is a gap between orchestration ambition and orchestration reality. Enterprises are consolidating fast onto the major model platforms: Anthropic’s Claude is the primary platform for 40%, more than double any rival, followed by Microsoft (18%) and OpenAI (13%). The choice is driven by “model gravity” — native alignment with a state-of-the-art base model (21%) — and success is judged by reliable, multi-step execution (task completion reliability 32%, multi-step workflow management 28%). Yet asked to assess their portfolios honestly, 71% say a quarter or fewer of their deployed “agents” are true multi-step orchestrated workflows rather than single-prompt chatbot wrappers, and only 10% have crossed the halfway mark. The orchestration layer is being built well ahead of the orchestrated portfolio it is meant to run.

That gap shapes the architecture enterprises are putting in place. By the end of 2026 a clear majority (51%) expect a hybrid control plane — provider-native plus external orchestration — and only 6% expect to hand control to a provider-managed service, because vendor lock-in (35%) is the risk they fear most if control lives inside a model provider. Investment follows the build-out: agent workflow tooling leads the spend (34%), with security and permissions enforcement (25%) behind. And fiscal control lags throughout — more than a quarter (27%) have no real-time way to stop a runaway agent before the bill arrives.

Methodology

VentureBeat fielded this survey as part of its ongoing Pulse Research series, this instrument focused on enterprise agent orchestration. Responses are filtered to organizations with 100 or more employees (n=101), drawn from a single June 2026 wave; because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends.

By organization size the sample is spread evenly across the enterprise bands: 100–499 employees, 2,500–9,999, and 50,000+ (21% each), with 10,000–49,999 and 500–2,499 (19% each). By role it is senior and buyer-credible: product and program managers (15%), CIO/CTO/CISO (13%), consultants and advisors (13%), and a spread of data, AI, and engineering directors and VPs, with an “Other” function at 18%. On purchasing, 81% are recommenders, influencers, or final decision-makers for AI solutions (66% recommender/influencer, 15% final decision-maker). Technology/Software is the largest industry at 44%, followed by Financial Services (17%) and Healthcare/Life Sciences (8%).

At 101 respondents the sample is robust enough to read directionally with reasonable confidence, though it remains self-selected and is not a probability sample.

Finding 1: Orchestration runs on model-provider platforms

Anthropic’s Claude leads; open frameworks are marginal

We asked which agent orchestration platform enterprises primarily use today. The answer concentrates on the major model providers — and on one in particular.

A note on reading these shares. As described in the methodology section, the respondents are self-selected, and this question asked them for a single primary platform — so the figures measure which platform leads each enterprise's deployment, within a self-selected audience of AI-active technical decision-makers. A sample built this way can diverge substantially from spend-weighted market measures, and each VB Pulse survey draws its own sample with its own company-size mix, so vendor figures should not be compared across our surveys either. Read these shares as a portrait of where this cohort has placed its primary orchestration bet today, rather than as market share.

The model platforms dominate. Anthropic, Microsoft, OpenAI, Google, and Amazon together account for roughly 80% of deployments (81 of 101), while the open frameworks (LangChain/LangGraph) and custom in-house builds that anchor engineering discussion sit in single digits. Anthropic’s lead — 40%, more than double the next platform — mirrors the “model gravity” selection logic in Finding 2: enterprises are choosing the orchestration layer that comes with the model they want to build on. As with the security vendors in the prior agent-security wave, the tools that define the category in technical circles are not yet where enterprise deployment concentrates. A small 3% are not orchestrating at all.

Respondents rate the platforms they run at 3.94 out of 5 overall (109 answered), with “value for money” specifically at 3.94 and “ease of implementation” the weakest score, at 3.85 — placing orchestration near the bottom of our five-tracker satisfaction range, ahead of only evaluation tooling. A rating just under 4 out of 5, from users of whom 96% plan to change their orchestration approach within the year, reads as provisional acceptance: the platforms work well enough to run today, and not well enough to stop the search for something better. The ratings sit alongside near-universal intent to change; this is a layer enterprises tolerate more than they love.

Finding 2: Model gravity drives platform selection

The base model, not the tooling, decides the platform

We asked what most influenced the orchestration platform choice. The single largest factor is the pull of the underlying model — though flexibility and ease of development follow close behind.

Model gravity leading is the selection-side explanation for Anthropic’s platform lead: enterprises pick the orchestration environment closest to the frontier model they have standardized on. But the next tier complicates the picture — flexibility across models and tools (17%) and ease of development (17%) say enterprises also want to avoid being trapped by that choice, foreshadowing the lock-in fear in Finding 6. Security and permissions (14%) and total cost of ownership (11%) round out a pragmatic buying logic. Performance (latency/memory) sits last at 4%, a reminder that at this stage of adoption the binding constraints are model fit and optionality, not raw speed.

Finding 3: The job is reliable multi-step execution

Enterprises just orchestration by whether it completes the work

We asked what enterprises optimize for — their primary success metric for orchestration. Reliability and multi-step workflow management dominate; developer- and user-facing metrics trail.

Task completion reliability (32%) and multi-step workflow management (28%) together account for 59% of responses (60 of 101): orchestration succeeds, in the enterprise view, when it reliably carries a task through multiple steps to completion. Developer productivity (17%) matters but is secondary — the inverse of its prominence in framework discussion — and end-user experience (9%) is a minor concern, consistent with orchestration being an internal execution problem rather than a UX one. This reliability-first standard is exactly what makes the Chatbot Trap finding so pointed: enterprises define success as dependable multi-step execution, yet most of their deployed “agents” do not yet do multi-step work at all.

The trap is not evenly distributed. Splitting the sample by organization size, 77% of smaller enterprises say a quarter or fewer of their agents do true multi-step work, against 62% of larger ones. Larger enterprises are meaningfully further into genuine multi-step deployment; the chatbot trap is, directionally, a mid-market condition.

Finding 4: Consolidate, productionize, and build in-house

Three strategic moves are nearly tied for the year ahead

We asked what major change enterprises anticipate in their orchestration strategy over the next 12 months. Three moves cluster at the top, almost evenly split.

The top three — building in-house control (25%), standardizing on one framework (24%), and moving agents from sandbox to production (23%) — are statistically indistinguishable and tell a single story: enterprises are moving from experimentation to operational consolidation. They want fewer frameworks, more production exposure, and more ownership of the control layer; only 4% expect no change. The appetite for custom in-house control planes is notable alongside the platform concentration in Finding 1 — enterprises are standardizing on model-provider platforms while simultaneously planning to wrap them in control logic they own, the hybrid posture that Finding 6 makes explicit.

Finding 5: Nearly seven in 10 plan to switch — and the biggest group of movers has no shortlist 

The strategic change enterprises anticipate (previous finding) comes with vendor motion attached. Asked whether they plan to adopt a new, additional, or replacement agent orchestration platform in the next twelve months, more respondents are moving here than in any other layer we track.

Asked which platforms they are considering, the most common answer among those in motion is none yet: 29% of all respondents are evaluating without a shortlist, the largest single response after "not considering a change." Among named candidates, OpenAI leads at 16%, followed by LangChain/LangGraph at 12% and Anthropic at 7% — and notably, the independent frameworks draw roughly double their current usage footprint in forward consideration, the same pattern our security tracker found for specialist vendors. Read with this report's concentration and lock-in findings, the picture completes itself: the major model-platform providers hold roughly four-fifths of today's primary usage, vendor lock-in has become the leading fear, 96% anticipate a strategic change — and now the purchase intent to act on all of it, with the largest bloc of buyers still undecided. The most concentrated layer of the agentic stack is also, as of June, the least settled.

Finding 6: Investment flows to workflow tooling

Tooling and permissions lead the spend; monitoring trails

We asked which orchestration-related investment will grow most next year. Agent workflow tooling leads, with security and permissions enforcement behind.

Workflow tooling leading (34%) is the budget-side expression of the reliability-and-multi-step priority in Finding 3: the money is going to the machinery that strings steps together dependably. Security and permissions enforcement (25%) and scaling infrastructure (20%) follow — the investments required to take agents from sandbox into production, the strategic move in Finding 4. Monitoring and debugging draws a smaller 11%, with another 11% reporting flat budgets. The weight on tooling, permissions, and scaling over pure observability signals that enterprises are spending to build and harden orchestration, not merely to watch it run.

Finding 7: The control plane will be hybrid — and lock-in is why

Enterprises expect to split control between providers and their own layer

We asked where enterprises expect the primary control plane for agents to live by the end of 2026, and what worries them most if that control sits inside a model-provider platform. A clear majority expect a hybrid model — and vendor lock-in is the reason.

Hybrid control is the dominant expectation by a wide margin (51%), and only 6% expect to hand control to a provider-managed service outright. Read together, the hybrid, custom, and externally-abstracted options — every architecture that keeps control at least partly outside the provider — sum to 88% (89 of 101). The reason surfaces directly when we asked about the risk of provider-resident control: vendor lock-in leads at 35% (35 of 101), ahead of security and permissioning limitations (28%) and inflexibility across models and tools (21%). The pattern echoes the prior wave’s “don’t trust the model to police itself” posture — here, enterprises will build on a provider’s platform but decline to be governed entirely by it. The hybrid control plane is the architectural hedge against the lock-in they most fear.

The June figure asserting a preference for a hybrid control plane marks movement from earlier. In the April–May survey (n=145), only 34% expected a hybrid control plane, and a greater number (12%) expected to hand control fully to a provider-managed service. These two snapshots don’t yet measure a confirmed longitudinal trend — but the direction of the conversation is unambiguous: toward keeping control.

Lock-in is also a new arrival as a top concern. In the April–May wave, the leading concern was security and permissioning limitations (32%), with lock-in second at 24%; by June the two had traded places. The worry about provider platforms appears to be maturing from whether they can be secured to whether they can be replaced.

Finding 8: The chatbot trap — most “agents” aren’t agents yet

Enterprises admit most deployments are still chatbot wrappers

We asked enterprises to assess their portfolios honestly: what share of their deployed “agents” are true multi-step orchestrated workflows versus simple single-prompt chatbot wrappers. The answer is the defining finding of this wave.

This is the gap at the center of the report. Combining the bottom two bands, 71% of enterprises (72 of 101) say a quarter or fewer of their deployed “agents” are genuinely orchestrated — and just 10% (10 of 101) have crossed the halfway mark. The ambition documented in the earlier findings — model-provider platforms, reliability-first success metrics, production rollouts, a deliberate control architecture — runs well ahead of the deployed reality, which remains overwhelmingly single-prompt assistants dressed as agents. This is less a contradiction than a roadmap: the platforms, budgets, and strategies are being put in place precisely because the orchestrated portfolio is still so thin. The open question for later waves is how fast the reality closes on the ambition.

Finding 9: Fiscal control is still reactive

Only a minority can stop a runaway agent before the bill arrives

Finally, we asked how enterprises enforce fiscal control over agent token consumption — the risk that an autonomous loop exhausts a budget before anyone intervenes. Most rely on native caps or after-the-fact monitoring; real-time programmatic control is the exception.

More than a quarter of enterprises (27%) admit they have no real-time, programmatic way to stop an agent before a budget-breaking bill arrives — they learn of it from the logs afterward. Another 32% lean entirely on the native caps and throttles built into their primary platform, a control only as good as the provider’s tooling and one that ties back to the lock-in concern of Finding 6. The enterprises building custom gateways (23%) or exploiting cross-model routing to arbitrage cost (19%) are the ones treating token burn as an engineering problem to be controlled deterministically. As with orchestration maturity, fiscal control is an area where the operational reality lags the ambition: agents are moving toward production faster than the cost-control plane around them is being built.

It’s worth noting, a split appears according to company size: roughly one in three enterprises under 2,500 employees (34%) exercises only reactive control of agent spend, against 20% of larger enterprises — directional figures, but consistent with the chatbot-trap split. The mid-market is running the least mature agents on the least instrumented budgets.

The bottom line: The layer is real; most of the agents aren't yet

Organizations with 100 or more employees describe an orchestration strategy that is consolidating quickly and maturing slowly. They are standardizing — for now — on model-provider platforms, which collectively hold roughly four-fifths of primary usage, chosen for the gravity of the underlying model, and they judge success by reliable multi-step execution. Investment is flowing to workflow tooling and permissions, the strategy is to consolidate frameworks and push agents into production, and the control plane they expect is deliberately hybrid, because vendor lock-in is the risk they fear most. But the standardization is provisional: 68% plan to adopt a new, additional, or replacement orchestration platform within twelve months — the highest switching intent of any layer we track — and the largest group of those movers has not yet shortlisted a candidate. Today's concentration describes where enterprises are, and visibly does not describe where they intend to stay.

But the honest self-assessment punctures the ambition. Seventy-one percent say a quarter or fewer of their deployed "agents" are truly orchestrated, only 10% are past the halfway mark, and more than a quarter cannot stop a runaway agent in real time. The orchestration layer — the platforms, the budgets, the control architecture — is being built ahead of the orchestrated portfolio it is meant to run. At 101 respondents in a single June wave this reads as a clear directional signal rather than a precise measurement: enterprises have decided how they want to orchestrate agents well before most of their agents are doing anything an orchestration layer is for. The questions for subsequent waves are whether the deployed reality closes the gap on the ambition — and, with nearly seven in ten buyers in motion and most of them undecided, which platforms the settled stack finally lands on.

Based on survey responses from 101 qualified enterprise respondents (100+ employees), drawn from a single June 2026 wave. Because this is one wave rather than a pooled multi-month sample, results read directionally rather than as a confirmed trend. Respondents include product and program managers, CIOs, CTOs and CISOs, consultants and advisors, and directors and VPs of data, AI, and engineering, across Technology/Software, Financial Services, Healthcare, and other sectors.

Data security is a core part of how Kaspersky protects its products and users. In this video we talk about our approach to protecting data, the measures behind it and why continuous improvement matters. Watch to learn how we build trust through responsibility and resilience.

Find more details in the report: https://kas.pr/7jar

#kaspersky #esg #sustainability #cybersecurity

In this video, we explain what sustainability means for Kaspersky. Learn how respect for human rights, adherence to regulatory requirements and meaningful contribution to society and environment shape our guiding principles. From our commitment to transparency, resilient supply chains to measures that ensure our products can be trusted, we're actively working towards a safer future.

Find more details in the report: https://kas.pr/7jar

#kaspersky #esg #sustainability #cybersecurity

India online safety rules are being strengthened as the government steps up measures to protect children and other users from harmful digital content, cyber risks and emerging threats linked to artificial intelligence. The government said its policies are aimed at ensuring an open, safe, trusted and accountable internet, with recent measures focusing on child safety, privacy protection, faster content removal and stronger platform responsibilities.

The Information Technology Act, 2000, and the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021, form the core legal framework governing online safety and intermediary responsibilities in India. The government has also highlighted the Digital Personal Data Protection Act, 2023, and recent amendments to the IT Rules as part of its broader approach to digital safety.

India Online Safety Rules Tighten Platform Responsibilities

Under the IT Rules, intermediaries are required to observe due diligence and inform users that they must not host, display, upload, modify, publish, transmit, update or share content that is harmful to children or violates applicable laws.

Recent amendments require social media platforms and other intermediaries to remove unlawful content within three hours of receiving an order from a competent court or a reasoned intimation from the appropriate government or its agency.

The government has also outlined specific obligations related to content involving nudity, impersonation and other sensitive material. In cases involving certain complaints about content featuring full or partial nudity, exposed private areas or artificially morphed images, intermediaries must take reasonable and practicable measures to remove or disable access within two hours.

Government Targets Harmful Content and OTT Platforms

The government said it has taken action against online platforms and OTT services over unlawful and obscene content. In the last two years, 50 OTT platforms have been disabled for public access in India for displaying obscene content and violating provisions including Sections 67 and 67A of the IT Act, Section 294 of the Bharatiya Nyaya Sanhita and the Indecent Representation of Women (Prohibition) Act, 1986.

The government also said it has taken note of reports alleging the dissemination of advertisements linked to child sexual abuse material (CSAM) on social media platforms and sought a detailed report from the concerned intermediary. The National Commission for Protection of Child Rights has also issued notices to the concerned platforms.

India Strengthens AI-Generated Content Safeguards

The government has also expanded its regulatory focus to address risks associated with AI-generated content and synthetically generated information. Amendments to the IT Rules introduce requirements for clear labelling and traceable metadata for permissible AI-generated content, allowing users to identify synthetically generated material.

The framework also strengthens platform accountability and requires greater user awareness about the legal consequences of unlawful AI-generated content. The rules specifically cover harmful material including CSAM, non-consensual intimate imagery and impersonation.

Platforms are required to deploy reasonable and appropriate technical measures, including automated tools or other mechanisms, to prevent users from creating, modifying, publishing or sharing synthetically generated information that violates applicable laws.

Significant Social Media Intermediaries are also required to make reasonable efforts to deploy technical measures to proactively identify content depicting rape, child sexual abuse or conduct, as well as content identical to information previously removed.

Child Privacy and Digital Addiction Remain Key Concerns

The Digital Personal Data Protection Act, 2023, provides a framework for protecting children's privacy online. It mandates parental consent for processing children's personal data and prohibits practices considered detrimental to children's well-being, including tracking, behavioural monitoring and targeted advertising directed at children.

The government has also highlighted digital addiction as a serious challenge affecting children and young people. The Economic Survey 2025-26 noted potential impacts on cognitive development, academic performance, workplace productivity, social connectedness and mental health, alongside risks linked to cyberbullying, compulsive gaming, social media and online gambling.

Cyber Awareness Reaches 11.37 Lakh Participants

Alongside regulatory measures, the government is expanding cyber awareness initiatives through the Information Security Education and Awareness project. So far, 6,650 awareness workshops have been conducted nationwide, reaching more than 11.37 lakh participants, including students, teachers, law enforcement officials, government personnel and members of the public.

The government has also highlighted digital safety initiatives in education. The PRAGYATA Guidelines provide a framework for safe online learning and responsible use of social media and electronic devices. CBSE has introduced digital etiquette and cybersecurity training initiatives, while NCERT has incorporated cyber safety into its curriculum.

The measures were outlined by Union Minister for Electronics and Information Technology Ashwini Vaishnaw in the Lok Sabha on July 22, 2026, as the government continues to strengthen its approach to c child protection and accountability across India's digital ecosystem.

Chick-fil-A data security incident may have exposed personal and account information belonging to customers after unauthorized parties launched an automated attack against the company’s website and mobile application. The incident targeted certain Chick-fil-A One accounts between June 17 and June 19, 2026, using account credentials obtained from a third-party source.

Chick-fil-A said it identified suspicious login activity involving certain Chick-fil-A One accounts and immediately took steps to prevent further unauthorized access. The company launched an investigation and determined on July 13, 2026, that unauthorized parties may have accessed information stored in affected accounts.

The company notified affected customers about the incident and outlined the types of information that may have been involved, along with steps taken to secure accounts and protect customers.

Chick-fil-A Data Security Incident Linked to Automated Attack

According to the notice sent to customers, the Chick-fil-A data security incident involved an automated attack against the company's website and mobile application. The attackers used account credentials, including email addresses and passwords, that were obtained from a third-party source.

The activity took place over a three-day period between June 17 and June 19. After identifying suspicious login activity, Chick-fil-A moved to prevent additional unauthorized activity and began investigating the incident.

The company said its investigation later determined that unauthorized parties may have accessed information in customers' Chick-fil-A One accounts.

Chick-fil-A One Accounts May Have Exposed Personal Information

The information potentially accessed in the incident varied depending on what customers had stored in their accounts.

Potentially affected data may have included customers' names, email addresses, Chick-fil-A One membership numbers and mobile pay numbers. The information may also have included QR codes, the last four digits of credit or debit card numbers, and the amount of Chick-fil-A credit, such as an e-gift card balance, associated with an account.

For customers who had additional information saved to their accounts, the potentially exposed data may also have included the month and day of their birthday, phone number and address.

The company did not state that all listed information was accessed for every affected customer.

Chick-fil-A Resets Passwords and Removes Payment Methods

Following the incident, Chick-fil-A said it took immediate action to protect affected accounts. The measures included forcing log-outs from impacted accounts and removing stored payment methods.

The company also restored the balances of impacted Chick-fil-A One accounts. As an additional measure for affected customers, Chick-fil-A said it added rewards to their accounts.

The company said it continues to enhance its security, monitoring and fraud controls to reduce the risk of similar incidents in the future.

Chick-fil-A Urges Customers to Update Passwords

Chick-fil-A said it has reset the passwords associated with affected accounts and urged customers to update their passwords as soon as possible.

The company recommended that customers choose strong, difficult-to-guess passwords that are unique to their Chick-fil-A accounts and not reused across other websites or online services.

The company also encouraged customers to remain vigilant against potential identity theft and fraud. Customers were advised to review their credit reports and account statements carefully and check for any activity that they do not recognize.

The Chick-fil-A data security incident highlights the risks associated with compromised account credentials being used in automated attacks. While the company said it took steps to secure affected accounts and restore balances, customers are being encouraged to take additional precautions to protect their personal information and online accounts.

OpenAI and Hugging Face are investigating an AI security incident involving an AI agent that compromised infrastructure while models were being evaluated for advanced cyber capabilities. The incident was detected and contained after the models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure.

Hugging Face disclosed the incident last week, while OpenAI has now shared preliminary findings from its investigation. According to OpenAI, the activity involved a combination of models, including GPT 5.6 Sol and a more capable pre-release model, with reduced cyber refusals for evaluation purposes. The models were being tested against a benchmark designed to measure advanced cyber capabilities.

OpenAI described the incident as unprecedented and said it is continuing its investigation alongside Hugging Face. The company said the findings are being shared to help defenders understand what occurred and assess the capabilities of increasingly advanced AI models.

OpenAI and Hugging Face Investigate AI Security Incident

The incident took place during an internal evaluation designed to test models against advanced exploitation scenarios involving complex attack paths. OpenAI said the evaluation was conducted without production classifiers that normally prevent models from pursuing high-risk cyber activity.

The testing environment was designed to be highly isolated, with network access limited to package installation through an internally hosted third-party software system that functions as a proxy and cache for package registries.

Despite these restrictions, the models spent substantial inference compute attempting to obtain open Internet access. During this process, they identified and exploited a zero-day vulnerability in the package registry cache proxy. OpenAI said the vulnerability has since been responsibly disclosed to the vendor.

The models then carried out privilege escalation and lateral movement within the research testing environment until they reached a node with Internet access.

Models Chained Vulnerabilities Across Infrastructure

After obtaining Internet access, the models inferred that Hugging Face could host models, datasets and solutions related to the ExploitGym evaluation. The models then searched for ways to obtain secret information that could help them bypass the evaluation.

In one example described by OpenAI, the models chained multiple attack vectors, including stolen credentials and zero-day vulnerabilities, to identify a remote code execution path on Hugging Face servers.

OpenAI's security team detected the anomalous activity internally. Hugging Face's security team and agents also detected and stopped the activity on its infrastructure. The company had already begun containment and forensic reconstruction using its own open-source models when the two organizations connected.

Both companies are continuing to investigate the incident and its impact.

OpenAI Strengthens Security Controls After Incident

As part of its response, OpenAI said it is implementing stricter infrastructure configuration controls while identified vulnerabilities are patched. The company acknowledged that these measures could come at the cost of research velocity and said its Safety and Security Committee is being briefed on the controls and their impact.

OpenAI is also working with Hugging Face on the forensic investigation and has responsibly disclosed the identified zero-day vulnerability in the internally hosted third-party software.

The company has also brought Hugging Face into its trusted access program and is supporting its teams in using AI model capabilities to strengthen defenses.

OpenAI said it is improving protections around future training and evaluations, including stronger safeguards for model alignment, cybersecurity and monitoring during internal testing. The company noted that deployment safeguards were intentionally disabled during this evaluation because the goal was to measure cyber vulnerabilities.

AI Cyber Capabilities Raise New Security Concerns

OpenAI said the incident demonstrates the need for AI security and safety measures to keep pace with rapidly advancing model capabilities. The company is strengthening containment, monitoring, access controls and evaluation practices used during model development.

The incident also highlights how advanced models can potentially discover and exploit novel attack paths in real-world systems without access to source code. OpenAI said increasingly capable models should also be used defensively to help security teams identify weaknesses, understand vulnerability chains and accelerate remediation.

Hugging Face CEO Clem Delangue said the incident demonstrates the importance of collaboration in addressing AI safety and security challenges. Both organizations said they will continue investigating the incident and share additional findings and best practices as the work progresses.

Read more →

The post Device Code Phishing: Turning a Convenience Feature Into an MFA Bypass appeared first on IT Security News.

Gemini 3.5 Flash Cyber Focuses on Scalable Cybersecurity 

Flash Cyber Improves Large-scale Code Analysis 

Benchmark Results Show Competitive Performance 

Real-world Cybersecurity Deployment 

Kenya is investigating a Kenya cyberattack that temporarily defaced President William Ruto’s official website with an anti-government message and a Bitcoin ransom demand for five bitcoins, reportedly worth about $330,000. The attackers replaced the website’s homepage with the message, displayed a cryptocurrency wallet address and threatened to publish unspecified information about President William Ruto unless the ransom was paid.

The website was hacked on Saturday, July 18, 2026. Following the incident, access to the presidential website was temporarily restricted as authorities began containment, forensic analysis and restoration efforts. According to local media reports, access to the website was restored by Monday.

Kenya Cyberattack Prompts Incident Response

Kenya’s Ministry of Information, Communications and the Digital Economy confirmed that the official website of the President had been affected by a cybersecurity incident.

The ministry said that after the incident was detected, the ICT Authority immediately activated established cybersecurity incident response protocols.

As a precautionary measure, access to the presidential website was temporarily restricted to facilitate containment, forensic analysis and restoration efforts.

The ministry said appropriate mitigation measures had since been implemented and that restoration of the website was underway.

At the time of the statement, the government said there was no evidence of unauthorized access to sensitive data, data exfiltration or loss of information. It also stated that government systems and digital services remained secure and operational.

The ICT Authority is working with relevant government agencies and technical partners to conduct a comprehensive forensic investigation and establish the full circumstances surrounding the incident.

Kenya President William Ruto Cyberattack Investigation

The Kenya President William Ruto cyberattack involved the defacement of the president’s official website. The attackers replaced the homepage with an anti-government message, displayed a cryptocurrency wallet address and demanded five bitcoins.

The attackers also threatened to publish unspecified information about President William Ruto if the ransom was not paid.

The government has not reported evidence of unauthorized access to sensitive data or data exfiltration. The ongoing forensic investigation is expected to establish the circumstances surrounding the incident and determine the extent of the attack.

Kenya Government Website Hack Follows Earlier Incidents

The latest Kenya government website hack follows previous cyber incidents involving government digital services and websites.

In July 2023, Kenya’s eCitizen platform, which is used for dozens of public services, was disrupted by a cyberattack. The incident affected agencies including the National Transport and Safety Authority and Kenya Power.

On November 17, 2025, hackers launched a coordinated attack on several government websites, including the presidency’s portal. The websites were temporarily knocked offline, while some pages were replaced with extremist messages.

According to the information provided by local media, the government later blamed a group calling itself PCP@Kenya, restored the affected platforms and promised stronger cyber defences.

Bitcoin Ransom Demand Targets Presidential Website

The latest incident involved a Bitcoin ransom demand for five bitcoins, reportedly valued at approximately $330,000. The attackers displayed a cryptocurrency wallet address and threatened to release unspecified information about the president.

It remains unclear from the available information whether the attackers accessed systems or data beyond the presidential website. The Kenyan government has said there is currently no evidence of unauthorized access to sensitive data, data exfiltration or loss of information.

The ICT Authority and relevant government agencies are continuing their forensic investigation to establish how the incident occurred and determine the full circumstances surrounding the Kenya cyberattack.

The models aim to make AI agents faster, smarter, and cheaper at scale. Google is pricing Gemini 3.6 Flash at $1.50 per one million input tokens and $7.50 per one million output tokens through its application programming interface (API), while Gemini 3.5 Flash-Lite costs a staggeringly cheap $0.30/$2.50 per million tokens in/out.

Compare that to the $1.50/$9.00 per 1M tokens for Gemini 3.5 Flash, and the $2/$12 for Gemini 3.1 Pro Preview, and the savings are considerable. However, Google's prior generation Gemini 3.1 Flash-Lite still remains the search giant's "most cost-efficient" model at $0.25/$1.50 per 1M tokens. Yet, it remains 2X slower than the new, more expensive Gemini 3.5 Flash-Lite, giving those enterprises who value speed more "bang" for their buck.

VB Frontier AI Model API Pricing Comparison Chart (Late July 2026 Shortlist)

No price was provided yet for the specialty Gemini 3.5 Flash Cyber model, which, as its name would imply, is designed for cybersecurity researchers and red teamers to patch bugs.

While the prices are among the middle-low end of all major AI models globally, the fact that Google designed them to use less tokens overall also should drive down costs for enterprises beyond what the sticker price shows (since you'll be paying for fewer total tokens at any rate).

Gemini 3.6 Flash and Gemini 3.5 Flash-Lite are available immediately through the Gemini API in Google AI Studio and Android Studio, as well as within the consumer Gemini application and Google Search. According to a separate Google blog post, Gemini 3.5 Flash Cyber will be available "exclusively available to governments and trusted partners via CodeMender soon" — CodeMender being Google's proprietary AI code bug-fixing agent released last year.

As with previous Gemini models, these are all proprietary and "closed source," thus, they can only be obtained through Google's official API and that of its partners, as opposed to an open-source license like MIT or Apache 2.0.

One conspicuous omission noted by developers on X and social media: where is the larger, more powerful, flagship Gemini 3.5 Pro model Google previously alluded would be released this summer? After all, Gemini 3.1 Pro, the prior flagship, debuted back in February 2026, and rivals OpenAI and Anthropic have since released several more generations of flagship updates far more powerful than Google's.

Google technical staffer Logan Kilpatrick responded to one such inquiry on X, writing: "Gemini 3.5 Pro is currently testing with partners and we plan to make it broadly available as soon as it’s ready."

Google's release signals that the immediate future of AI lies in agentic capabilities—systems that operate autonomously over extended periods.

If early large language models are akin to massive, fuel-hungry freight trains capable of hauling incredible loads at immense cost, the new Flash series represents a fleet of nimble, hyper-efficient hybrid delivery vans.

Efficiency gains ranging from 17% to 65% reduced tokens for strong results on third-party benchmarks

Under the hood, Gemini 3.6 Flash achieves significant efficiency gains. The model reduces output token usage by 17% compared to its predecessor, Gemini 3.5 Flash, according to the Artificial Analysis Index maintained by the independent third-party AI benchmarking group of the same name.

In specific long-horizon software engineering benchmarks like DeepSWE, which measures how well agents complete multi-step engineering tasks from scratch, the token savings reach up to 65%.

This reduction means the model requires fewer reasoning steps and tool calls to complete the exact same multi-step workflow. Think of token efficiency like fuel economy in a vehicle.

When an AI model takes a convoluted path to solve a problem, it burns through more computational fuel, driving up the final cost for the developer. By streamlining its internal logic, Gemini 3.6 Flash arrives at the correct answer faster and cheaper.

While Google's materials did not specify the exact architectural or algorithmic changes used to achieve this token efficiency, they noted that the model "takes fewer reasoning steps and tool calls to accomplish multi-step workflows" and exhibits reduced "verbosity."

The official model cards released by Google reveal that both Gemini 3.6 Flash and Gemini 3.5 Flash-Lite feature a 1-million-token input context window alongside a max output limit of 64,000 tokens, with both models sharing a knowledge cutoff date of March 2026.

Respectable benchmark performance at low cost

The technological improvements extend to concrete capabilities. Gemini 3.6 Flash scores 49% on the DeepSWE benchmark, a notable increase from the 37% achieved by version 3.5.

It also pushes machine learning engineering performance higher, scoring 63.9% on MLE-Bench compared to 49.7% previously. Furthermore, Google integrates computer use as a built-in client-side tool via the Gemini API and Gemini Enterprise, reflecting an OSWorld-Verified score of 83.0%, up from 78.4%.

The model also tackles knowledge work with greater proficiency, outperforming its predecessor on benchmarks like GDPval-AA v2 by moving from a score of 1349 to 1421.

To ensure safety amidst these capability upgrades, Google deploys enhanced Frontier Safety safeguards. These protections harden the model against jailbreaks and mitigate risks in Chemical, Biological, Radiological, and Nuclear domains, as well as cyber offense misuses.

The engineering team trains the model to minimize refusals for beneficial uses, striking a necessary balance between strict security and practical utility.

Models for low-cost coding, agentic, and cybersecurity use cases — respectively

Google divided its new offerings into three distinct products tailored for different operational needs.

Gemini 3.6 Flash serves as the heavy-duty workhorse of the trio. It handles complex coding, intricate knowledge work, and multimodal processing with improved precision. Enterprise customers utilize it for demanding tasks such as complex document parsing, intricate chart and data analysis, and long-form report drafting.

The model executes complex code migrations using multi-agent orchestration frameworks with lower latency and higher quality than earlier iterations. Furthermore, 3.6 Flash aids in developing photographic texture extractors for 3D workflows using canvas interfaces.

Gemini 3.5 Flash-Lite targets environments where high throughput and absolute minimal latency are non-negotiable. Google designates it as the fastest model in the 3.5 series.

As measured by Artificial Analysis, the model processes 350 output tokens per second, making it highly effective for agentic search and massive document processing workloads. Artificial Analysis notes this is about twice as fast as prior generation model Gemini 3.1 Flash-Lite.

Developers can configure 3.5 Flash-Lite to prioritize low-latency execution for high-volume tasks using minimal thinking levels, or engage higher thinking levels to process complex multi-step subagent workloads.

Despite its lite designation, it outperforms the standard Gemini 3 Flash on several key agentic and coding evaluations, including SWE-Bench Pro, where it scores 54.2% compared to 49.6%, and OSWorld-Verified, scoring 74.0% versus 65.1%.

The model extracts product features from massive datasets, generates interactive web design concepts, and scales receipt translation seamlessly.

The third product, Gemini 3.5 Flash Cyber, represents a highly specialized deployment. Google fine-tuned this model specifically to find and fix cybersecurity vulnerabilities. It integrates directly with Google's CodeMender agent.

In practice, multiple 3.5 Flash Cyber agents work concurrently to produce a single, comprehensive vulnerability report, achieving competitive performance at the frontier on the CyberGym benchmark, even getting within range of Anthropic's much-hyped Mythos model.

Google did not specify an exact numerical cost for 3.5 Flash Cyber, stating only that it is fine-tuned "at a lower price per token than larger models.

Commercial licensing only

The licensing framework for the new Gemini models carries profound implications for developers and enterprise users. Google deploys Gemini 3.6 Flash and 3.5 Flash-Lite under a commercial, proprietary API model. Unlike open-source software governed by licenses such as the MIT License or the GNU General Public License, developers do not gain access to the underlying model weights, training data, or source code.

An MIT or GPL license grants users the freedom to download the codebase, modify the internal architecture, self-host the deployment, and distribute the software infrastructure independently. In contrast, Google's API approach means developers essentially rent access to the intelligence on a strict metered basis. Every prompt and generated response travels through Google's managed servers, incurring a cost based on the strict pricing structure of $1.50 per million input tokens for 3.6 Flash.

This commercial tethering restricts deployment flexibility. Enterprises cannot air-gap the models entirely on their own local secure hardware without establishing specialized, high-tier enterprise agreements with Google Cloud. Developers remain bound by Google's acceptable use policies, arbitrary rate limits, and network requirements, creating a permanent dependency on Google's infrastructure uptime and terms of service.

The licensing for Gemini 3.5 Flash Cyber proves even more restrictive. Acknowledging the dual-use nature of cybersecurity AI—which attackers can weaponize just as easily as defenders can use it to patch systems—Google is for now making the model only available behind a limited-access pilot program, similar to the trend kicked off by Anthropic's Mythos model with its Project Glasswing program, and continued by OpenAI with its staggered rollout for GPT-5.6.

In this case, Google is making 3.5 Flash Cyber exclusively available to governments and trusted partners. This strict gatekeeping prevents open access, prioritizing systemic security over widespread developer innovation.

Looking ahead

Google DeepMind continues to iterate rapidly, but the gap in its product line remains apparent. While the Flash series excels in speed and economy, the industry eagerly awaits the deployment of Gemini 3.5 Pro to gauge Google's absolute frontier capabilities.

Simultaneously, the company confirms that pre-training for Gemini 4 has already commenced.

Until the next major flagship release materializes, developers must optimize their systems using the highly efficient, yet purposefully constrained, Flash architecture.

The models aim to make AI agents faster, smarter, and cheaper at scale. Google is pricing Gemini 3.6 Flash at $1.50 per one million input tokens and $7.50 per one million output tokens through its application programming interface (API), while Gemini 3.5 Flash-Lite costs a staggeringly cheap $0.30/$2.50 per million tokens in/out.

Compare that to the $1.50/$9.00 per 1M tokens for Gemini 3.5 Flash, and the $2/$12 for Gemini 3.1 Pro Preview, and the savings are considerable. However, Google's prior generation Gemini 3.1 Flash-Lite still remains the search giant's "most cost-efficient" model at $0.25/$1.50 per 1M tokens. Yet, it remains 2X slower than the new, more expensive Gemini 3.5 Flash-Lite, giving those enterprises who value speed more "bang" for their buck.

VB Frontier AI Model API Pricing Comparison Chart (Late July 2026 Shortlist)

No price was provided yet for the specialty Gemini 3.5 Flash Cyber model, which, as its name would imply, is designed for cybersecurity researchers and red teamers to patch bugs.

While the prices are among the middle-low end of all major AI models globally, the fact that Google designed them to use less tokens overall also should drive down costs for enterprises beyond what the sticker price shows (since you'll be paying for fewer total tokens at any rate).

Gemini 3.6 Flash and Gemini 3.5 Flash-Lite are available immediately through the Gemini API in Google AI Studio and Android Studio, as well as within the consumer Gemini application and Google Search. According to a separate Google blog post, Gemini 3.5 Flash Cyber will be available "exclusively available to governments and trusted partners via CodeMender soon" — CodeMender being Google's proprietary AI code bug-fixing agent released last year.

As with previous Gemini models, these are all proprietary and "closed source," thus, they can only be obtained through Google's official API and that of its partners, as opposed to an open-source license like MIT or Apache 2.0.

One conspicuous omission noted by developers on X and social media: where is the larger, more powerful, flagship Gemini 3.5 Pro model Google previously alluded would be released this summer? After all, Gemini 3.1 Pro, the prior flagship, debuted back in February 2026, and rivals OpenAI and Anthropic have since released several more generations of flagship updates far more powerful than Google's.

Google technical staffer Logan Kilpatrick responded to one such inquiry on X, writing: "Gemini 3.5 Pro is currently testing with partners and we plan to make it broadly available as soon as it’s ready."

Google's release signals that the immediate future of AI lies in agentic capabilities—systems that operate autonomously over extended periods.

If early large language models are akin to massive, fuel-hungry freight trains capable of hauling incredible loads at immense cost, the new Flash series represents a fleet of nimble, hyper-efficient hybrid delivery vans.

Efficiency gains ranging from 17% to 65% reduced tokens for strong results on third-party benchmarks

Under the hood, Gemini 3.6 Flash achieves significant efficiency gains. The model reduces output token usage by 17% compared to its predecessor, Gemini 3.5 Flash, according to the Artificial Analysis Index maintained by the independent third-party AI benchmarking group of the same name.

In specific long-horizon software engineering benchmarks like DeepSWE, which measures how well agents complete multi-step engineering tasks from scratch, the token savings reach up to 65%.

This reduction means the model requires fewer reasoning steps and tool calls to complete the exact same multi-step workflow. Think of token efficiency like fuel economy in a vehicle.

When an AI model takes a convoluted path to solve a problem, it burns through more computational fuel, driving up the final cost for the developer. By streamlining its internal logic, Gemini 3.6 Flash arrives at the correct answer faster and cheaper.

While Google's materials did not specify the exact architectural or algorithmic changes used to achieve this token efficiency, they noted that the model "takes fewer reasoning steps and tool calls to accomplish multi-step workflows" and exhibits reduced "verbosity."

The official model cards released by Google reveal that both Gemini 3.6 Flash and Gemini 3.5 Flash-Lite feature a 1-million-token input context window alongside a max output limit of 64,000 tokens, with both models sharing a knowledge cutoff date of March 2026.

Respectable benchmark performance at low cost

The technological improvements extend to concrete capabilities. Gemini 3.6 Flash scores 49% on the DeepSWE benchmark, a notable increase from the 37% achieved by version 3.5.

It also pushes machine learning engineering performance higher, scoring 63.9% on MLE-Bench compared to 49.7% previously. Furthermore, Google integrates computer use as a built-in client-side tool via the Gemini API and Gemini Enterprise, reflecting an OSWorld-Verified score of 83.0%, up from 78.4%.

The model also tackles knowledge work with greater proficiency, outperforming its predecessor on benchmarks like GDPval-AA v2 by moving from a score of 1349 to 1421.

To ensure safety amidst these capability upgrades, Google deploys enhanced Frontier Safety safeguards. These protections harden the model against jailbreaks and mitigate risks in Chemical, Biological, Radiological, and Nuclear domains, as well as cyber offense misuses.

The engineering team trains the model to minimize refusals for beneficial uses, striking a necessary balance between strict security and practical utility.

Models for low-cost coding, agentic, and cybersecurity use cases — respectively

Google divided its new offerings into three distinct products tailored for different operational needs.

Gemini 3.6 Flash serves as the heavy-duty workhorse of the trio. It handles complex coding, intricate knowledge work, and multimodal processing with improved precision. Enterprise customers utilize it for demanding tasks such as complex document parsing, intricate chart and data analysis, and long-form report drafting. The model executes complex code migrations using multi-agent orchestration frameworks with lower latency and higher quality than earlier iterations. Furthermore, 3.6 Flash aids in developing photographic texture extractors for 3D workflows using canvas interfaces.

Gemini 3.5 Flash-Lite targets environments where high throughput and absolute minimal latency are non-negotiable. Google designates it as the fastest model in the 3.5 series.

As measured by Artificial Analysis, the model processes 350 output tokens per second, making it highly effective for agentic search and massive document processing workloads. Artificial Analysis notes this is about twice as fast as prior generation model Gemini 3.1 Flash-Lite.

Developers can configure 3.5 Flash-Lite to prioritize low-latency execution for high-volume tasks using minimal thinking levels, or engage higher thinking levels to process complex multi-step subagent workloads.

Despite its lite designation, it outperforms the standard Gemini 3 Flash on several key agentic and coding evaluations, including SWE-Bench Pro, where it scores 54.2% compared to 49.6%, and OSWorld-Verified, scoring 74.0% versus 65.1%.

The model extracts product features from massive datasets, generates interactive web design concepts, and scales receipt translation seamlessly.

The third product, Gemini 3.5 Flash Cyber, represents a highly specialized deployment. Google fine-tuned this model specifically to find and fix cybersecurity vulnerabilities. It integrates directly with Google's CodeMender agent.

In practice, multiple 3.5 Flash Cyber agents work concurrently to produce a single, comprehensive vulnerability report, achieving competitive performance at the frontier on the CyberGym benchmark.

Google did not specify an exact numerical cost for 3.5 Flash Cyber, stating only that it is fine-tuned "at a lower price per token than larger models.

Commercial licensing only

The licensing framework for the new Gemini models carries profound implications for developers and enterprise users. Google deploys Gemini 3.6 Flash and 3.5 Flash-Lite under a commercial, proprietary API model. Unlike open-source software governed by licenses such as the MIT License or the GNU General Public License, developers do not gain access to the underlying model weights, training data, or source code.

An MIT or GPL license grants users the freedom to download the codebase, modify the internal architecture, self-host the deployment, and distribute the software infrastructure independently. In contrast, Google's API approach means developers essentially rent access to the intelligence on a strict metered basis. Every prompt and generated response travels through Google's managed servers, incurring a cost based on the strict pricing structure of $1.50 per million input tokens for 3.6 Flash.

This commercial tethering restricts deployment flexibility. Enterprises cannot air-gap the models entirely on their own local secure hardware without establishing specialized, high-tier enterprise agreements with Google Cloud. Developers remain bound by Google's acceptable use policies, arbitrary rate limits, and network requirements, creating a permanent dependency on Google's infrastructure uptime and terms of service.

The licensing for Gemini 3.5 Flash Cyber proves even more restrictive. Acknowledging the dual-use nature of cybersecurity AI—which attackers can weaponize just as easily as defenders can use it to patch systems—Google is for now making the model only available behind a limited-access pilot program, similar to the trend kicked off by Anthropic's Mythos model with its Project Glasswing program, and continued by OpenAI with its staggered rollout for GPT-5.6.

In this case, Google is making 3.5 Flash Cyber exclusively available to governments and trusted partners. This strict gatekeeping prevents open access, prioritizing systemic security over widespread developer innovation.

Looking ahead

Google DeepMind continues to iterate rapidly, but the gap in its product line remains apparent. While the Flash series excels in speed and economy,

the industry eagerly awaits the deployment of Gemini 3.5 Pro to gauge Google's absolute frontier capabilities.

Simultaneously, the company confirms that pre-training for Gemini 4 has already commenced.

Until the next major flagship release materializes, developers must optimize their systems using the highly efficient, yet purposefully constrained, Flash architecture.

Summary

Successful exploitation of these vulnerabilities could result in an attacker accessing sensitive credentials, disrupting connected infrastructure, or manipulating physical equipment, which could present a physical safety risk.

The following versions of Tycon Systems TPDIN-Monitor-WEB2 are affected:

• TPDIN-Monitor-WEB2 2.3.9 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Abdiwelli Guled reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-21

Legal Notice and Terms of Use

Summary

Multiple Siemens products are affected by unquoted search path vulnerability in IAM Client. This could allow an authenticated local attacker to perform privilege escalation. Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends countermeasures for products where fixes are not, or not yet available.

The following versions of Siemens IAM Client are affected:

• COMOS V10.4.5 vers:intdot/<10.4.5.0.2 
• COMOS V10.6 vers:intdot/<10.6.1 
• Designcenter NX vers:intdot/<2512.7000 
• Simcenter 3D vers:intdot/<2512.7000 
• Simcenter Femap V2506 vers:intdot/<2506.0003 
• Simcenter Femap V2512 vers:intdot/<2512.0002 
• Simcenter Nastran vers:intdot/<2606 
• Simcenter STAR-CCM+ vers:intdot/<2606 
• Solid Edge SE2025 vers:intdot/<225.0.13.3 
• Solid Edge SE2026 vers:intdot/<226.0.04.003 
• Teamcenter Visualization V2412 vers:intdot/<2412.0012 
• Teamcenter Visualization V2506 vers:intdot/<2506.0009 
• Teamcenter Visualization V2512 vers:intdot/<2512.2605 
• Tecnomatix Plant Simulation V2404 vers:intdot/<2404.0022 
• Tecnomatix Plant Simulation V2504 vers:intdot/<2504.0010 
• Tecnomatix Process Simulate vers:intdot/<2606 

Background

• Critical Infrastructure Sectors: Chemical, Critical Manufacturing, Energy
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Siemens ProductCERT reported this vulnerability to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-288252 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

Palo Alto Networks has published [1] information on vulnerabilities in PAN-OS. This advisory lists the related Siemens Industrial products affected by these vulnerabilities. Customers are advised to consult and implement the workarounds provided in Palo Alto Networks' upstream security notifications. [1] https://security.paloaltonetworks.com/

The following versions of Siemens RUGGEDCOM APE1808 with Palo Alto Networks Virtual NGFW are affected:

• RUGGEDCOM APE1808 vers:all/* 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Siemens ProductCERT reported these vulnerabilities to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of this vulnerability.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-104023 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

CADRA is affected by multiple zlib and Foxit vulnerabilities. Siemens has released a new version for CADRA and recommends to update to the latest version. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.

The following versions of Siemens CADRA are affected:

• CADRA vers:intdot/<2511, vers:all/* 

Background

• Critical Infrastructure Sectors: Chemical, Commercial Facilities, Communications, Energy
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Siemens ProductCERT reported these vulnerabilities to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of this vulnerability.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-470355 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could allow an attacker to impersonate an authorized user on the FTSP server, resulting in unauthorized access to system configurations.

The following versions of Rockwell Automation FactoryTalk Services Platform are affected:

• FactoryTalk Directory (FTSP) 6.60 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.

Revision History

• Initial Release Date: 2026-07-21