“The cloud is just someone else’s computer.” The old sysadmin joke has held up better than many forecasts from the last decade. After years of cloud-first mandates, digital transformation roadmaps, and hyperscaler marketing, more companies are taking a second look at where their workloads actually belong.

Not out of nostalgia, but because the industry has matured enough to recognize that “cloud-always” was never more rational than “on-premises-always.” In Europe, the reassessment has an added layer: data sovereignty, regulatory compliance, and a growing unease about relying on infrastructure that may not be fully shielded from foreign government access.

The numbers are hard to ignore

The scale of the shift is difficult to dismiss. According to a Barclays CIO Survey from Q4 2024, 86% of CIOs planned to move some workloads from public cloud to private or on-premises environments, the highest figure the survey had recorded. An IDC study from the same year found that roughly 80% of organizations expected to repatriate a share of compute and storage within the following twelve months.

Only 8% were planning a full exit. Nobody is shutting down their AWS accounts en masse; what’s happening is a selective repositioning, driven by a question that should probably have been asked much earlier: which workloads genuinely benefit from cloud, and which ones are just paying a premium for someone else’s hardware?

Case studies: when the bill finally arrived

37signals: $2 million saved per year, and counting

If the cloud repatriation movement has a poster child, it’s David Heinemeier Hansson (DHH), CTO of 37signals, the company behind Basecamp and HEY. After finding that the company was spending more than $3.2 million per year on AWS, DHH argued for a radical shift. The company invested roughly $600k in Dell servers and cut its compute bill by about $1.5 million to $2 million a year.

But that was the compute side. In later write-ups, 37signals documented the migration of billions of files off S3 and the operational model behind 10 petabytes of data in Pure Storage. The specifics of later savings are harder to pin to a single primary source, but the trajectory is clear: less recurring cloud spend, more direct control.

As DHH put it: “Cloud can be a good choice in certain circumstances, but the industry pulled a fast one convincing everyone it’s the only way.”

Dropbox: the original repatriator

Dropbox was doing cloud repatriation before anyone called it that. Between 2013 and 2016, the company migrated the vast majority of its data from AWS to proprietary colocation facilities via an internal project codenamed “Magic Pocket”. According to later technical reporting, that move led to nearly $75 million in savings over two years, along with dramatically improved control over the storage stack.

GEICO: $300M a year with little visible return

In 2013, GEICO began migrating more than 600 applications to the cloud. By 2021, it was reportedly spending over $300 million annually on cloud services, and internal stakeholders were struggling to justify the expense. Trade-press coverage of the case emphasized a now-familiar problem: for data-heavy estates, cloud storage costs can dominate the bill surprisingly quickly. GEICO subsequently began a selective repatriation of its most storage-intensive workloads.

Ahrefs: the math that changed everything

Ahrefs laid out the arithmetic in public: in a technical write-up, the company claimed its bare-metal approach had avoided roughly $400 million in cloud costs. The pattern running through all these examples is the same: once workloads become large, steady, and storage-heavy, owning your hardware starts to look very different from renting it.

A more honest accounting of cloud pros and cons

Cloud was not a mistake. But it is a tool, not a destiny, and like every tool it works well in some contexts and poorly in others.

What cloud genuinely does well

For workloads with unpredictable traffic (consumer apps, seasonal e-commerce, early-stage startups), the ability to scale on demand without upfront CapEx is hard to beat. You pay for what you use, when you use it.

Cloud-native development (managed Kubernetes, CI/CD pipelines, Infrastructure-as-Code) can dramatically accelerate delivery cycles. Provisioning environments in minutes rather than weeks is a genuine productivity gain for development teams.

Offloading database administration, backups, patch cycles, and hardware lifecycle to a provider creates real savings for organizations without dedicated infrastructure teams. Not every company can run its own data center, and not every company should.

Multi-region failover, global CDN, and built-in disaster recovery that would cost millions to replicate on premises come standard with every major cloud provider.

Managed AI/ML platforms, petabyte-scale data warehouses, and globally distributed databases are extraordinarily hard to build in-house. For many organizations, cloud remains the only practical path to these capabilities.

Where cloud consistently underdelivers

Cost predictability

The Producer Price Index for cloud computing services rose by 6.4% between September 2023 and May 2024. Cloud pricing is not magically trending toward zero. For stable, predictable workloads, the pay-as-you-go model is often more expensive than owned hardware over a 3-5 year horizon. Egress fees (what you pay to move data out of the cloud) are especially easy to underestimate during procurement.

Vendor lock-in

Migrating into cloud is frictionless by design. Migrating out of cloud, or between providers, is significantly harder. Proprietary APIs, managed service dependencies, data format lock-in, and pricing structures tied to data transfer all create a gravitational pull that makes exit far more expensive than the initial architecture review ever anticipated.

Performance for high-throughput, low-latency workloads

For AI/ML training on large proprietary datasets, real-time industrial IoT processing, or high-frequency financial analytics, the shared nature of cloud infrastructure introduces variance and latency that dedicated hardware simply does not. For consistent, predictable workloads, on-premises infrastructure can offer better and more stable performance at a fraction of the long-term cost.

Security posture and control

The shared responsibility model gets a lot of airtime, but in practice it is frequently misunderstood. According to Palo Alto Networks’ State of Cloud Security Report 2025, 53% of organizations identify lax IAM practices as a top challenge and a leading vector for data exfiltration. The Verizon 2025 DBIR found that 30% of breaches now involve third-party components, double the previous year’s figure, a finding that maps directly to cloud supply-chain risk.

The most instructive case is probably Capital One’s 2019 breach. A misconfigured web application firewall on AWS allowed an attacker to exploit the cloud metadata service via SSRF and access over 106 million customer records, including Social Security numbers and bank account details. Amazon’s response was that the vulnerability lay in Capital One’s application layer, not in AWS itself. That distinction is the shared responsibility model in a nutshell: the provider secures the infrastructure, the customer secures everything running on top of it. In practice, the boundary is blurry enough that even large, well-funded security teams can get it wrong.

On-premises environments allow security teams to implement least-privilege at the hardware level, maintain audit trails end to end, and respond to incidents without waiting on a provider’s tooling or disclosure timelines. Repatriating organizations consistently report improved visibility as a secondary benefit. That said, on-prem security is not free: it requires dedicated staff, continuous patching, physical controls, and the discipline to maintain what you now fully own.

AI on proprietary data

Companies fine-tuning large language models or building domain-specific AI on confidential internal data have a strong incentive to keep that work off shared infrastructure. Even if the probability of data leakage is low, the residual risk is often incompatible with IP protection requirements in many sectors. This is becoming one of the fastest-growing reasons to invest in on-premises or private cloud infrastructure.

The security trade-off: no free lunch either way

Repatriation is often framed as a security win, and in many respects it can be. But it would be dishonest to pretend that running your own infrastructure is inherently safer. The real picture is more nuanced.

Cloud providers do some things exceptionally well. The hyperscalers invest billions in physical security, DDoS mitigation, encryption at rest and in transit, and global threat intelligence. Most organizations cannot match that depth of investment on their own. Managed security services (SIEM, SOAR, threat detection) are mature, widely available, and improving rapidly.

The problem is what sits on top. Misconfigurations, overly permissive IAM roles, exposed storage buckets, unrotated secrets, forgotten API keys: these are not infrastructure failures, they are application- and configuration-layer mistakes that happen at the customer level. The CSA Top Threats to Cloud Computing report consistently ranks misconfiguration and inadequate identity management among the top risks. The IBM Cost of a Data Breach Report, published annually with the Ponemon Institute, continues to show that breaches involving cloud environments tend to cost more and take longer to contain than those in purely on-premises estates.

On-premises security gives you full control, but demands the staff to exercise it. Patching cycles, firewall rule management, physical access controls, backup testing, log retention, and 24/7 monitoring all need people. For organizations with experienced security operations teams, that control translates into better posture. For organizations that repatriate workloads without scaling their SecOps capability accordingly, the outcome can be worse than the cloud setup they left behind.

Hybrid architectures create the widest attack surface. This is the part that rarely gets enough attention. An estate split across on-premises, private cloud, and one or more public providers multiplies the number of identity boundaries, network perimeters, and configuration standards that need to be maintained in parallel. Consistent policy enforcement, centralized logging, and unified incident response across all environments require serious tooling and discipline.

The honest conclusion: moving workloads on premises can improve your security posture, but only if you invest in the operational capability to manage it. Repatriation is not a security strategy by itself.

The European dimension: sovereignty is not optional

For European organizations, the calculus goes beyond cost. Cloud repatriation is increasingly a matter of legal and regulatory necessity.

GDPR: the baseline

The General Data Protection Regulation established strict rules on personal data processing, cross-border transfers, and data subject rights. The Schrems II ruling invalidated the Privacy Shield framework and forced European regulators to look much more closely at US-based cloud providers. The EU-US Data Privacy Framework, adopted in 2023, provides a new legal basis for transfers, but it is still viewed by many practitioners as politically fragile. For that reason, keeping personal data within EU borders remains the easiest posture to defend.

The CLOUD Act: the elephant in the room

In 2025, a point that legal analysts had raised for years became harder to dismiss in public debate: US cloud providers cannot offer an absolute guarantee that European data will never be reachable through US legal mechanisms. The CLOUD Act is central to that debate. In testimony before the French Senate, Microsoft France’s general manager stated under oath that he could not guarantee French citizens’ data was protected from US authority access. Google, Amazon, and Salesforce have made similar acknowledgments in other contexts. That tension between the CLOUD Act and European data-protection expectations is shaping infrastructure decisions in both the public and private sectors.

NIS2: cybersecurity supply-chain obligations

The NIS2 Directive, which entered into force in January 2023 and had to be transposed by member states by 17 October 2024, explicitly requires organizations in critical sectors to assess and manage cybersecurity risks introduced by their supply chains, including cloud service providers. In practice, this creates a formal obligation to evaluate concentration risk and, in some cases, to maintain control over critical infrastructure components. The ENISA Threat Landscape, updated annually, provides the European reference framework for these risk assessments and consistently highlights supply-chain attacks and cloud-infrastructure threats among the top concerns. Regulators increasingly expect documented evidence that cloud dependencies have been assessed and that alternatives exist.

DORA: exit strategies for financial services

The Digital Operational Resilience Act entered into force in 2023 and has applied since 17 January 2025. It requires financial institutions to demonstrate that they can continue operating through severe disruption involving major technology providers. That means maintaining documented exit strategies and preserving business continuity even when a critical ICT provider becomes unavailable. For banks, insurers, and investment firms, this has accelerated investment in hybrid architectures with a credible on-premises fallback layer.

EU Data Act: the newest layer

The EU Data Act entered into force on 11 January 2024 and has applied since 12 September 2025. Among other things, it requires providers of data-processing services to reduce barriers to switching and to take legal, technical, and organizational measures against unlawful third-country access to non-personal data held in the EU. That does not eliminate lock-in overnight, but it does make provider switching and eventual exit easier than before.

Taken together, these regulations are reshaping the European compliance environment. Cloud-only architectures face increasing scrutiny, and the ability to demonstrate local control over data is becoming both a competitive and a legal differentiator.

Cloud-also, not cloud-only

The real problem is that “cloud-first” quietly became “cloud-always”, and many organizations are now paying for that simplification in ways they never fully modeled up front.

The market itself has absorbed this lesson. The hybrid cloud market was valued at approximately $85 billion in 2022 and is projected to reach $262 billion by 2027. Almost no organization repatriating workloads today is abandoning cloud entirely. They are building architectures that put each workload where it belongs. Cloud for elastic, innovation-heavy, globally distributed services. On-premises or private cloud for steady-state, data-intensive, compliance-critical, and proprietary-AI workloads.

The better framework is simpler than it sounds: right workload, right environment. It takes more architectural discipline up front, but it produces better outcomes over time.

For European organizations, it goes beyond good engineering. Under GDPR, NIS2, DORA, and the EU Data Act, it may be the only defensible position left.

If you have been following my open-source work, you probably know MalHunt, the memory forensics tool I built to automate malware hunting on top of Volatility. Yesterday I pushed a significant batch of updates that, taken together, amount to a near-complete rewrite of the project. Here is what changed and why it matters.

From a script to a proper Python package

The most visible change is structural. The original malhunt.py was a single 317-line script: practical, but not particularly maintainable or extensible. That file is gone. The codebase now lives under src/malhunt/ as a properly organized Python package:

src/malhunt/
├── core.py        # orchestration logic
├── volatility.py  # Volatility3 wrapper
├── scanner.py     # YARA, Malfind, and network scanners
├── artifacts.py   # artifact collection and ClamAV integration
├── models.py      # data models
├── utils.py       # utilities and YARA rule handling
└── __main__.py    # CLI entry point

This separation makes each component independently testable and easier to extend. Speaking of testing: the project now ships with a full test suite covering the core logic, the scanner layer, and the Volatility wrapper, something the old script lacked entirely.

The package is installable via both pip and poetry, and dependency management is now handled through a pyproject.toml with a locked poetry.lock file. No more environment guesswork.

The big migration: Volatility2 → Volatility3

If you have been using the old version, the most important thing to know is that MalHunt now targets Volatility3 exclusively. The legacy v0.1 relied on Volatility2 and its --profile= flag; that approach is now gone.

Volatility3 works differently: it does automatic OS and version detection, it exposes plugins with updated names (windows.vadyarascan, windows.malfind, windows.netscan, and so on), and it handles symbol tables rather than profiles. The underlying subprocess management has been rebuilt accordingly, with proper timeout handling and a configurable retry strategy.

A migration guide is available in docs/MIGRATION.md for anyone upgrading from v0.1.

Smarter YARA rule handling

YARA rule management was one of the weakest points of the old tool. The new version addresses it on multiple levels.

Downloading rules from Yara-Forge. Instead of cloning a git repository, MalHunt now fetches the full Yara-Forge rule bundle directly via HTTP, caches it under ~/.malhunt/, and automatically refreshes it when the cache is more than a day old.

Text-based sanitization. Before using any YARA file, MalHunt strips out rule blocks that rely on imports or features not supported by the version of yara-python used by Volatility: import "math", import "cuckoo", import "hash", imphash patterns, and pe.number_of_signatures. This alone prevents a large category of failures on the 3300+ rules included in the Yara-Forge bundle.

Compile-and-prune validation. The sanitization pass handles known-bad patterns, but the YARA format is complex enough that a rule file can still fail to compile for other reasons. The new validate_and_prune_yara_rules_file() function takes a different approach: it actually compiles the file using yara-python, and when a compilation error occurs, it locates the offending rule block, removes it, and tries again. This loop repeats until the file compiles cleanly or a maximum iteration count is reached. The result is a YARA file that is guaranteed to work, even when the upstream source contains rules with edge-case syntax or undocumented dependencies.

Handling large scans without giving up. YARA scanning over a memory dump is slow. On large images it can easily take 15–20 minutes. The new VolatilityConfig now exposes a dedicated yara_timeout parameter (defaulting to 15 minutes) separate from the general command timeout. If a scan times out and the threshold is still below one hour, MalHunt doubles it and retries automatically. This prevents the tool from aborting unnecessarily on large forensic images, the kind you typically encounter in enterprise incident response.

Better error messages that actually help

One of the most frustrating aspects of working with Volatility is decoding its error output. MalHunt now puts effort into turning those errors into actionable feedback.

Structured error objects. The VolatilityError exception now carries the plugin name, the return code, and the full stdout and stderr from the failed command. Downstream code, and log files, can show exactly what went wrong and where, rather than just “Volatility command failed.”

Symbol recovery. When Volatility fails because Windows symbol tables (PDB files) are missing, MalHunt now attempts to recover automatically. It parses the error output for download URLs, tries both .pdb and .pd_ filename variants, and downloads the files into the correct directory structure. If the automatic recovery does not succeed, the tool generates a ready-to-run shell script containing all the download commands, so you can fix the problem in one step rather than hunting through Volatility documentation.

YARA dependency detection. A separate check catches the situation where yara-python is not installed in the same Python environment that the vol binary uses. In that case MalHunt raises a specific error:

“YARA backend not available for Volatility. Install yara-python in the same Python environment used by ‘vol’ (or use yara-x), then retry.”

That single sentence saves a lot of time compared to staring at a generic plugin-not-available stack trace.

Documentation

The project now ships with a proper docs/ directory covering architecture decisions, installation instructions for various environments, a full usage reference with CLI examples, and a 400-line troubleshooting guide. Not the most glamorous part of a release, but probably the one most people will actually use.

Upgrading

If you were using the old version, the upgrade path is straightforward:

pip install --upgrade malhunt

Or from source:

git clone https://github.com/andreafortuna/malhunt.git
cd malhunt
poetry install

Make sure you have Volatility3 (≥2.0.0) installed and accessible as vol in your PATH. ClamAV integration remains optional.

If you were running v0.1 with Volatility2, read the migration guide first: the command-line interface has changed and the profile-based approach no longer applies.

What is next

A few things are still on my list: Linux memory dump support has been tested but could use more coverage, the ClamAV integration needs updating to handle newer daemon configurations, and I want to add structured JSON output for easier integration with SIEM pipelines and case management tools. Pull requests and issues are welcome on GitHub.

MalHunt is released under the MIT license. It is intended for authorized forensic analysis and security research only.

The symbol table labyrinth: Windows edition

The first and most disorienting problem is the complete elimination of profiles. In Volatility2, a profile tied the tool to a specific OS version and analysis proceeded with a single --profile=Win10x64_18362 argument. Volatility3 replaces this model with symbol tables, dynamically resolved compressed JSON files matched against a PDB GUID embedded in the memory image. In connected environments the framework contacts Microsoft’s symbol server automatically, downloads the matching PDB, converts it, and caches the result locally. The first run on a new kernel version is slow but subsequent ones are instant. For air-gapped environments, the JPCERT/CC offline usage guide documents how to pre-populate the cache on a connected machine using pdbconv.py and transfer the resulting files to the isolated workstation.

The second problem is subtler and harder to diagnose: the automagic PDB scanner failing to locate the correct kernel base address, causing the familiar Unsatisfied requirement plugins.*.nt_symbols error even with correctly placed symbol files. Running vol.py -f image.dmp -vvvv windows.info reveals which base addresses were attempted and whether the scanner exhausted its candidate list. In several cases, specifying the kernel virtual offset manually through the configuration system is the only path forward. If acquisition was performed inside a virtualised environment, disabling hardware virtualisation in BIOS before the next capture frequently resolves the issue at the source.

Linux, Android, and macOS: building symbols from scratch

The third problem hits anyone working outside the Windows ecosystem. Volatility3 has no centralised symbol distribution for Linux, Android, or macOS. Every kernel version and build configuration requires a custom-generated symbol table produced with dwarf2json, a Go utility that processes DWARF debug data from a vmlinux binary and a System.map file. The kernel must have been compiled with CONFIG_DEBUG_INFO=y. Most distribution kernels do not enable this flag in their production builds, but major distributions (Ubuntu, Debian, Fedora, RHEL) ship debug symbols in separate packages (linux-image-*-dbgsym on Debian/Ubuntu, kernel-debuginfo on RHEL/Fedora) that contain the unstripped vmlinux needed by dwarf2json. A full recompile is only necessary when no matching debug package exists for the target kernel version.

The fourth problem compounds the difficulty for Android emulator dumps. The kernel must be compiled from source using the exact toolchain version embedded in /proc/version, and the resulting vmlinux must produce a banner string that matches the memory dump character for character. A single invisible whitespace discrepancy causes Volatility3 to reject the symbol file without a clear explanation. Running vol.py banners on the dump before any other command verifies the expected banner and prevents hours of misdiagnosis.

The fifth problem is specific to macOS analysis. A Kernel Debug Kit (KDK) matching the exact OS build number must be downloaded from Apple’s developer portal. After running dwarf2json on the kernel DWARF bundle, the constant_data field in the resulting JSON must be manually populated with a base64-encoded Darwin banner string extracted from the target memory image. Forgetting this step or encoding the wrong banner produces the same “symbol table requirement not fulfilled” error seen on other platforms, but with no automatic resolution path available.

Performance regression: when analysis takes days

The sixth problem is one of the most surprising: dramatic, sometimes catastrophic performance degradation on specific plugins. windows.filescan on a typical Windows 10 image takes over an hour in Volatility3, versus under one minute in the previous framework. The timeliner plugin, which aggregates artefacts from dozens of sources across the entire image, has been observed running for over a hundred hours on large dumps without completing. The root cause is often the automagic stacker, which attempts multiple layer detection strategies sequentially before committing to a format. Each failed attempt carries measurable overhead. Specifying the layer type explicitly with --layer-type WindowsIntel bypasses the guesswork and can reduce startup time from several minutes to a few seconds on the same image. QEMU memory dumps are the worst-affected format: the layered structure triggers repeated stacker retries that render most plugins impractical until the dump is converted to raw using the built-in layerwriter command (vol.py -f dump.qemu -o output_dir layerwriter.LayerWriter).

The seventh problem is a specific pathological case: windows.memmap.Memmap entering an infinite page-mapping loop on certain system processes such as svchost.exe and sihost.exe. As documented in GitHub issue #1920, the plugin prints the table header and then consumes 100% CPU indefinitely, producing no rows and only terminating after several days or a manual interrupt. For affected PIDs, windows.vadinfo.VadInfo provides the virtual address descriptor information required in most investigations and completes in a reasonable time on the same processes that cause the hang.

The missing toolkit and the standalone binary problem

The eighth problem for practitioners migrating from Volatility2 is the absence of several plugins they relied on regularly. notepad and clipboard were not ported to Volatility3. Some, like notepad, were deliberately excluded because heap structure changes in modern Windows make the plugin fundamentally unreliable regardless of which framework hosts it. For text content buried in process memory, windows.strings fed with an offset-tagged string file produced by strings -o dump.mem > strings.txt provides an imperfect but functional substitute. However, as tracked in the long-running issue #876 in the Volatility3 repository, the offset mapping logic still has edge cases where strings confirmed present in dumped process memory go undetected, and the issue remains open after years of active discussion.

The ninth problem removed the portable deployment model that was standard practice in incident response: early versions of Volatility3 shipped without a standalone Windows executable. Analysts accustomed to dropping a single binary onto a forensic workstation found themselves with no equivalent option, and the missing binary became the most-commented issue in the entire repository. Official pre-compiled executables are now distributed alongside each tagged release and downloadable directly from the GitHub releases page without requiring a local Python installation, restoring the workflow that practitioners had built their field kits around.

Architectural culture shock and broken dependencies

The tenth problem is not a single error but a systematic architectural disruption affecting both daily usage and plugin development. The --profile= argument is gone. Plugin names are namespaced as windows.*, linux.*, and mac.*. The calculate() and render_text() pattern that structured every Volatility2 plugin has been replaced by a _generator() method yielding rows to a TreeGrid renderer. Class inheritance changed, dependency declarations moved into a requirements() function, and short option flags were removed entirely. The official Volatility2 to Volatility3 migration guide documents these changes comprehensively, but no documentation fully prepares an analyst for the operational cost of running familiar commands against a framework that no longer recognises them.

Woven through this architectural transition is a dependency problem that cripples many first installations. yara-python and pefile are listed as optional but practically mandatory for production use. Missing yara-python silently disables yarascan, vadyarascan, and mftscan. Missing pefile eliminates verinfo, netscan, netstat, and skeleton_key_check at import time. Running pip install pefile "yara-python>=3.8.0" capstone pycryptodome immediately after the base installation closes most of these gaps. On Windows, libyara.dll must be in the system PATH and the Python architecture must match the YARA binary architecture exactly, a constraint that silently breaks installations where system Python is 64-bit and the installed YARA wheel is 32-bit.

Despite all of this, the direction of travel is clear. The Volatility Foundation continues to close the feature gap with each release, and the underlying architecture of Volatility3 is genuinely better suited to modern memory analysis than its predecessor. The investment required to navigate these ten problems is real but not prohibitive, and it pays back quickly once the environment is correctly configured and the new mental model is internalised.

The hardware gap that defines the comparison

Apple built Face ID around dedicated hardware that most competitors have never replicated at scale. The TrueDepth camera system, introduced with the iPhone X in 2017 and refined across every subsequent generation, uses a dot projector, an infrared camera, and a flood illuminator to cast more than 30,000 invisible infrared points onto the user’s face. The TrueDepth system then reads the distortion of those dots to generate a precise depth map, while a separate infrared snapshot captures the resulting pattern. This is not image recognition in the conventional sense; it is a geometric measurement of the physical structure of a human face, performed in three dimensions and entirely independent of ambient light conditions.

Android manufacturers have historically taken a different path. The vast majority of Android phones, including flagship models from Samsung, OnePlus, and many others, perform facial recognition using the front-facing RGB camera. This 2D approach converts a standard photograph into a mathematical representation of facial geometry, measuring relative distances between the eyes, nose, mouth, and jawline. The process is fast and works reliably in daylight, but it is fundamentally different in its security profile. A photograph, a detailed mask, or even a video played on a second screen can, under certain conditions, defeat a purely 2D recognition system. This asymmetry in hardware capability is the root of almost every meaningful security difference between the two ecosystems.

How Face ID maps geometry into identity

Diagram of the Secure Enclave components. Source: Apple Platform Security.

The depth map generated by Apple’s TrueDepth hardware is converted into a mathematical model, informally referred to as a face vector, which is a compact numerical representation of the three-dimensional structure of the face. This vector captures structural information that no flat image can contain. A neural network running entirely on the device compares each unlock attempt against the stored vector, producing a confidence score; if that score exceeds a defined threshold, access is granted. Critically, neither the raw depth map nor the resulting vector ever leaves the device. Both are stored and processed exclusively within the Secure Enclave, a dedicated cryptographic coprocessor physically isolated from the main application processor and inaccessible even to the operating system itself.

The Secure Enclave is not merely a software boundary. It is a dedicated subsystem within the system-on-chip (SoC) with its own boot process, its own encrypted memory, and communication channels that the main application processor cannot read. Even if the application layer were fully compromised by malware or a privilege escalation exploit, the biometric data stored in the enclave would remain unreachable. Apple reports the probability of a random individual unlocking someone else’s device with Face ID at approximately one in one million, compared to one in fifty thousand for the older Touch ID fingerprint sensor. The system also adapts over time, gradually updating the stored vector to account for natural changes in appearance such as facial hair, eyeglasses, or the slower drift of aging. This continuous learning is performed without transmitting any data externally, maintaining the privacy model alongside the security one.

Android’s approach: algorithms over dedicated optics

BiometricPrompt architecture and the Trusted Execution Environment stack. Source: Android Open Source Project.

Google has pursued a different strategy on its recent Pixel line, and the evolution of that strategy illustrates how far software can extend the limits of biometric security without specialized hardware. After abandoning the dedicated 3D sensors of the Pixel 4, subsequent 2D face unlock implementations on Android were widely classified as a weaker biometric modality, acceptable for device unlock but not for authorizing financial transactions or accessing sensitive application data. The Android biometric security framework defines three security classes, from Class 1 (convenience only) to Class 3 (strong authentication), and for years face unlock sat below the threshold required for payment authorization or cryptographic key access.

With the Pixel 8, Google upgraded face unlock to Class 3 biometric, meaning it meets the same security bar as fingerprint authentication and can be used with the Android Keystore to protect cryptographic keys. The improvement came not from new sensors but from substantial advances in liveness detection, the algorithmic ability to distinguish a live human face from a static image or a three-dimensional replica. Modern liveness detection systems analyze micro-movements, skin texture variations, infrared reflectance patterns on devices equipped with appropriate illuminators, and temporal consistency across multiple frames captured during the brief unlock gesture. The result is a system that remains more theoretically vulnerable than Apple’s hardware-centric approach but is considerably harder to fool than earlier software-only implementations.

The storage model on Android is sandboxed but follows a different architecture. Biometric templates reside within the Trusted Execution Environment (TEE), implemented through ARM TrustZone technology, while cryptographic keys are safeguarded by a dedicated secure element like the Titan M2 chip on Google Pixel devices. The TEE provides strong isolation from the main OS, comparable in concept to Apple’s Secure Enclave, though the depth of that comparison depends on the specific implementation. The key challenge for Android is not any single device but the ecosystem as a whole: across hundreds of manufacturers and thousands of models, the quality of TEE implementation varies in ways that are difficult for end users or even administrators to evaluate without detailed technical documentation.

The threat model: spoofing, bypasses, and real-world attacks

The most operationally relevant question is not which system is theoretically stronger but which is more difficult to defeat under realistic adversarial conditions. Presentation attacks (using a physical or digital replica of the target’s face to deceive the sensor) represent the primary concern for any face-based biometric.

A 2D face unlock system is inherently vulnerable to attacks using high-resolution photographs, printed or displayed on a screen. Several older Android devices were publicly demonstrated to unlock using nothing more than an image retrieved from a social media profile, or even a video playing on another smartphone.

A popular demonstration by Unbox Therapy showing how the Samsung Galaxy S10’s 2D face unlock could be bypassed using a video.

Apple’s Face ID sets a substantially higher bar: defeating it requires a custom-crafted three-dimensional model of the target’s face with accurate depth representation and credible infrared reflectance properties, a task that is neither trivial nor inexpensive. However, researchers, such as those at the Vietnamese security firm Bkav, have successfully demonstrated proof-of-concept bypasses using highly detailed 3D-printed masks combined with 2D infrared images for the eyes.

Security researchers from Bkav demonstrating a proof-of-concept bypass of Apple’s Face ID using a specially crafted 3D mask. (Video via Reuters)

Law enforcement interaction represents a separate and often underappreciated dimension of the threat model. In documented cases across multiple jurisdictions, authorities have compelled individuals to unlock devices using biometric authentication, on the grounds that biometrics constitute physical evidence rather than testimonial disclosure protected against self-incrimination. The legal framework around this coercion varies by country, but the practical implication is that both Face ID and Android face unlock can be used to access a device without requiring the owner to disclose a passphrase. From this angle, the security difference between the two systems becomes less decisive than the shared vulnerability intrinsic to any biometric access control mechanism: the authenticator is always present and visible.

A subtler attack surface involves the neural network inference layer itself. Adversarial perturbations, carefully crafted and nearly imperceptible modifications to input data, can sometimes cause classification models to produce incorrect outputs. Since Android face unlock relies more heavily on learned feature representations, it is theoretically more exposed to this category of attack. In practice, such techniques require significant expertise and physical proximity to the target device. Apple’s reliance on raw depth measurements, rather than purely learned visual features, offers a degree of inherent resistance to adversarial input manipulation, since the depth sensor produces structured physical data that is harder to perturb than a pixel array.

What this means in practice for users and organizations

The security gap between the two systems is real, measurable, and architecturally significant. It does not, however, translate uniformly into elevated risk for every user in every context. For the vast majority of individuals using face unlock to avoid typing a PIN throughout the day, both systems provide adequate protection against casual access by strangers, opportunistic theft, or unsophisticated attackers. The adversary capable of defeating either system at scale remains confined, for now, to well-resourced state actors and highly specialized security researchers.

For organizations evaluating mobile device management policies or assessing risk for regulated industries, the distinction carries considerably more weight. Apple’s uniform hardware implementation across all Face ID devices means that the security properties of the biometric are predictable and consistent across an entire fleet. An IT administrator deploying iPhones in a financial services or healthcare environment can rely on the same depth-sensing architecture regardless of which iPhone model employees carry. Android’s heterogeneous ecosystem makes equivalent assurance difficult to provide. A Samsung Galaxy S25 and a budget device from a lesser-known manufacturer may both advertise face unlock, but the underlying implementation, from sensor quality to TEE integrity to software patch level, can differ dramatically.

The principle of least privilege suggests that sensitive operations, whether authorizing a wire transfer or accessing an encrypted credential vault, should require the strongest available authentication factor. On Apple hardware, Face ID satisfies this requirement natively and consistently. On Android, the answer depends on the specific device, the Android version, and the application’s own implementation of the BiometricPrompt API. Recent flagships from Google and Samsung running fully patched software come close to closing the gap in practical terms. Older or lower-tier devices running outdated Android versions do not. Any organizational security policy that treats Android face unlock as equivalent to Face ID without accounting for this variance is operating on an assumption that the hardware and software stack does not always support.

The face, whether read in three dimensions by a dedicated sensor or interpreted by a neural network trained on millions of images, remains among the most convenient biometric factors available on a consumer device. The technology behind it is not monolithic, and treating it as such is a security mistake. Understanding that projecting 30,000 infrared points onto a face and recognizing its photograph with a standard camera are architecturally different operations, with different attack surfaces and different failure modes, is the foundation of any informed decision about mobile authentication, whether you are choosing a phone for personal use or writing a biometric policy for an enterprise.

The NIS2 Directive (EU) 2022/2555 has fundamentally redefined what it means for a European organization to take cybersecurity seriously. Among its most significant shifts is the elevation of training from a recommended best practice to a binding legal obligation. Article 20 explicitly requires that management bodies of essential and important entities follow cybersecurity training, and encourages organizations to offer similar, regular training to their employees (a requirement further solidified by Article 21). This is not a formality. It is the normative foundation upon which the entire human layer of security now rests.

What makes this requirement particularly demanding is not its breadth, but its depth. Compliance is no longer satisfied by assigning an annual e-learning module and checking a box. Regulators, national supervisory authorities, and auditors now expect organizations to demonstrate that training is meaningful, measurable, and continuously updated. The standard has shifted from “did you train your staff?” to “can you prove the training worked, who received it, when, and how it aligned with your current threat landscape?”

The regulatory architecture: articles 20 and 21 as a combined mandate

Understanding how to structure a compliant training plan requires reading Article 20 and Article 21 together, not in isolation. Article 20 addresses governance and management accountability: board members and senior executives must personally undergo training to acquire sufficient knowledge to identify risks and assess cybersecurity risk-management practices. The personal liability dimension is crucial. Under NIS2, management can be held individually responsible for infringements, which transforms training from an HR matter into a boardroom imperative.

Article 21 then specifies the technical and organizational measures that entities must implement, listing “basic computer hygiene practices and cybersecurity training” as an explicit requirement within an all-hazards risk management framework. Training must be anchored to the organization’s broader risk posture, covering incident handling, business continuity, multi-factor authentication, backup procedures, and supply chain awareness. The two articles together make it clear that no training plan can be considered compliant if it operates as a standalone activity disconnected from risk assessment processes.

The financial stakes reinforce this reading. Essential entities face maximum fines of at least 10 million euros or 2% of global annual turnover (whichever is higher) for non-compliance, while important entities face maximum fines of at least 7 million euros or 1.4% of turnover (whichever is higher). These figures, combined with the possibility of personal liability for executives, make a defensible training program one of the most consequential investments an organization can make.

Designing a training plan that holds up under scrutiny

A compliant training plan is built on four pillars: scope, content, cadence, and evidence. Each one must be intentionally designed rather than assembled by default.

Scope determines who receives what. Not all employees carry the same risk exposure, and a well-structured plan acknowledges this through segmentation. The general workforce needs foundational cyber hygiene: recognizing phishing, using strong passwords and password managers, understanding how to report incidents, applying secure configurations, and practicing safe remote work habits. Mid-level management adds a layer covering incident response protocols, business continuity fundamentals, and an overview of NIS2 obligations relevant to their function. Senior management and board members require training specifically tailored to their legal obligations, risk oversight responsibilities, and the personal liability framework that Article 20 introduces. A training plan that fails to differentiate between these audiences is unlikely to survive a rigorous audit.

Content must map directly to identified risks. One of the most common gaps auditors identify is a mismatch between the threats documented in the organization’s risk register and the topics covered in its training modules. If a company has identified social engineering as a primary attack vector in its threat assessment, and its training program contains no phishing simulation or social engineering awareness module, that gap is an evidentiary liability. Content should be derived from the risk assessment, reviewed at least annually, and updated whenever the threat landscape shifts materially.

Cadence addresses the persistent misconception that annual training is sufficient. NIS2’s requirement for “regular” training implies a frequency calibrated to the pace of threat evolution and to the organization’s operational reality. Practical interpretations from national authorities and compliance frameworks suggest quarterly awareness touchpoints at minimum, supplemented by role-specific deep dives and just-in-time training triggered by incidents or newly discovered vulnerabilities. Phishing simulations, tabletop exercises, and live scenario walkthroughs are not optional embellishments; they are the mechanisms through which training transitions from passive consumption to active competency.

Building the evidence layer: what auditors actually want to see

The shift from policy-based assurance to evidence-based proof is perhaps the most operationally disruptive change NIS2 introduces. An auditor asking for proof of training compliance will not be satisfied by a list of employee names marked “completed.” What they require is granular, timestamped, exportable documentation that answers four specific questions: who was trained, what content they covered, when the training took place, and what their assessed performance was.

This means organizations need to invest in platforms or processes capable of producing this level of detail. Training records should include module-specific completion logs, assessment scores, remedial activity records for those who failed initial assessments, and separate documentation for management-level training that reflects their distinct obligations under Article 20. The ENISA technical implementation guidance reinforces that evidence must demonstrate not just activity, but effectiveness. Dashboards showing improvement trends in phishing simulation click rates, reductions in policy violation incidents, or increases in self-reported suspicious activity are the kind of data that demonstrate a living program rather than a dormant one.

Governance documentation must accompany training records to provide context. Version histories of training content showing how modules evolved in response to updated risk assessments, board meeting minutes confirming that management completed their mandated training, and formal approval signatures on the training plan itself are all components of a defensible evidence package. Without this layer, even an operationally excellent training program may fail to produce the compliance narrative an audit demands.

Making it defensible: the risk-linkage principle

A training plan is only as defensible as the logical chain connecting it to the organization’s formal risk management framework. Risk-linkage is the principle that transforms a training calendar into a compliance control. It means that every training topic can be traced back to a specific identified risk, that every update to the training curriculum is triggered by a documented change in the risk landscape, and that training outcomes feed back into the organization’s periodic risk reviews as measurable evidence of risk reduction.

In practice, this requires integrating the training program into the same governance cycle as the risk assessment. When a new vulnerability is identified, the training team receives a signal to assess whether existing content addresses it. When a sector-level threat intelligence report is published, relevant modules are reviewed for currency. When an incident occurs, post-incident analysis informs the next training iteration. This recursive loop is what compliance frameworks increasingly describe as the difference between a static program and a resilient one.

Organizations that build their training plans with this architecture, scope differentiated by role and risk, content anchored to threat intelligence, cadence calibrated to regulatory expectations, and evidence structured for auditability, are not simply meeting the minimum requirements of NIS2. They are building the kind of institutional security culture that the directive was designed to foster: one where cybersecurity awareness is not a compliance exercise, but an organizational capability embedded in daily operations and accountable at every level of the hierarchy.

In any enterprise environment, privileged accounts represent the highest-value target for attackers. These are not just administrator credentials; they encompass service accounts, DevOps pipelines, cloud management interfaces, and any identity with elevated permissions over critical systems. When one of these accounts is compromised, the consequences extend far beyond a single machine or dataset. Attackers can move laterally, escalate privileges, and reach the deepest layers of an organization’s infrastructure, often without triggering immediate alerts.

The numbers behind this threat are stark. According to research cited by Keeper Security, the global average cost of a data breach in 2024 reached $4.88 million, a figure that reflects not only the technical remediation but also legal fees, regulatory fines, and lasting reputational damage. The 2024 AT&T breach, which exposed data from more than 65 million former customer accounts, stands as a recent and instructive example of what happens when privileged access is left poorly managed on third-party cloud environments.

These incidents rarely originate from sophisticated zero-day exploits. In the majority of cases, the initial vector is a stolen or misused credential. Attackers rely on phishing, credential stuffing, or exploiting improperly decommissioned accounts to gain a foothold. Once inside, the presence of excessive or poorly monitored privileges allows them to escalate quickly and operate undetected for extended periods. The longer an attacker maintains access, the more costly the breach becomes, both in terms of direct financial impact and long-term erosion of customer trust.

Privileged Access Management (PAM) addresses this problem by establishing structured controls over who can access sensitive systems, under what conditions, and for how long. But PAM alone is no longer sufficient. The modern threat landscape demands that it be combined with the principles of Zero Trust, a security model built on the premise that no user, device, or network segment should ever be trusted by default.

Why traditional PAM models fall short

Legacy PAM implementations were designed for a different era: perimeter-based networks where internal users were generally considered trustworthy, and where administrative access was granted on a semi-permanent basis to a small number of system administrators. That model has not survived contact with cloud adoption, remote work, and the explosion of non-human identities in modern IT environments.

One of the most persistent weaknesses in traditional PAM is the concept of standing privileges: accounts that retain elevated permissions continuously, regardless of whether those permissions are actively needed. This approach dramatically widens the attack surface. A compromised account with standing admin rights is immediately dangerous, while a credential with no active privileges at the moment of breach offers an attacker far less leverage.

The problem becomes even more acute in hybrid and multi-cloud environments, where privileged accounts often span multiple platforms with different security models and management interfaces. An administrator who holds standing privileges across AWS, Azure, and on-premises Active Directory presents a single point of failure that, if compromised, grants an attacker access to the organization’s entire technology stack. Without centralized visibility and policy enforcement, security teams are forced to manage these risks in silos, inevitably leaving gaps.

Shadow IT compounds the problem further. Many organizations simply do not have a complete inventory of their privileged accounts. Shared credentials, dormant service accounts, and unmonitored automation pipelines create blind spots that security teams cannot defend. As Splashtop’s analysis of PAM challenges highlights, the lack of automated discovery and continuous classification of privileged accounts is one of the most common and dangerous gaps organizations face today.

Zero Trust as the architectural backbone

The Cloud Security Alliance defines Zero Trust PAM around three foundational assumptions: breaches will occur, trust must be continuously verified, and authentication must be adaptive and context-aware. These principles transform PAM from a static gatekeeping function into a dynamic, risk-responsive framework.

At the operational level, this translates into several concrete practices. Just-in-Time (JIT) access replaces standing privileges with time-bound elevations that are provisioned only when a specific task requires them and revoked automatically once the task is complete. A DevOps engineer, for instance, might be granted temporary root access for a deployment window of thirty minutes, after which the privilege is automatically removed. This model, endorsed by the CISA Zero Trust Maturity Model, shrinks the window of opportunity for attackers to exploit compromised credentials.

Multi-Factor Authentication, particularly phishing-resistant implementations such as FIDO2 hardware tokens and passkeys, adds another layer of defense. Combined with behavior-based anomaly detection, which can flag an administrator logging in from an unrecognized geolocation or accessing systems outside of business hours, adaptive authentication ensures that the verification process is not a one-time event at login but a continuous assessment throughout each session.

Micro-segmentation reinforces these access controls at the network level. By dividing the infrastructure into isolated security zones, each with its own access policies, organizations can contain the impact of a compromised privileged account. Even if an attacker gains elevated access to one segment, micro-segmentation prevents unrestricted lateral movement to other parts of the network. When combined with JIT provisioning and continuous authentication, micro-segmentation creates a layered defense architecture where each layer independently limits the attacker’s reach.

An often overlooked component of Zero Trust PAM is the principle of least privilege by design. Rather than granting broad access and later attempting to restrict it, organizations should define the absolute minimum set of permissions required for each role and function from the outset. This inversion of the default, from “allow unless denied” to “deny unless explicitly allowed”, fundamentally changes the security posture of the organization and reduces the blast radius of any single compromised identity.

Integrating PAM with the broader security ecosystem

PAM does not operate effectively in isolation. Its value multiplies when integrated with Identity Governance and Administration (IGA) systems, Access Management platforms, and Security Information and Event Management (SIEM) tools. This integration creates a unified audit trail across all user activities, privileged and otherwise, enabling security teams to correlate events, detect lateral movement, and respond to incidents with the context they actually need.

The treatment of non-human identities is a particularly critical and often underestimated dimension of this ecosystem. Service accounts, API keys, machine-to-machine tokens, and automated pipelines frequently carry elevated permissions and are rarely subject to the same scrutiny as human users. In many organizations, non-human identities outnumber human users by a factor of ten or more, yet they receive a fraction of the security attention. An attacker who compromises a service account can blend into legitimate traffic patterns, moving through cloud environments and on-premises networks with minimal detection risk.

Applying Zero Trust principles to these identities requires a dedicated strategy. Credentials for service accounts and API integrations should be rotated automatically on a short lifecycle, ideally through a secrets management platform that eliminates the need for hard-coded credentials in source code or configuration files. Each non-human identity should be scoped to the minimum set of permissions required for its function, and its activity should be monitored continuously for deviations from established baselines. Organizations that treat non-human identities as second-class citizens in their PAM strategy are leaving one of their largest attack surfaces effectively unguarded.

Insider threats require their own layer of attention. The danger does not come only from malicious actors; negligence and misconfiguration account for a significant share of privilege-related incidents. Duo Security’s research on PAM risks emphasizes that even well-designed PAM strategies can introduce new vulnerabilities if they are inconsistently monitored or poorly maintained, underscoring the need for continuous oversight rather than periodic audits.

Building a resilient PAM implementation

Translating Zero Trust principles into a functioning PAM implementation requires a structured approach. The starting point is always a comprehensive audit of the existing identity landscape: every privileged account, human or automated, must be discovered, classified, and assessed against the principle of least privilege. Accounts that retain more access than their function requires should be immediately remediated.

From there, organizations should prioritize the implementation of Role-Based Access Control (RBAC) combined with JIT provisioning workflows. Credential vaulting, where privileged passwords and keys are stored in an encrypted, centrally managed repository rather than shared informally or stored in configuration files, eliminates one of the most common vectors for credential theft. Session recording provides forensic value after incidents and serves as a behavioral deterrent during normal operations.

A robust PAM implementation must also account for the full lifecycle of privileged accounts. This includes automated provisioning and deprovisioning tied to HR and organizational events, so that when an employee changes roles or leaves the organization, their privileged access is adjusted or revoked immediately. Too often, accounts persist long after the business justification for their privileges has expired, creating a growing inventory of dormant credentials that attackers can exploit.

Equally important is the investment in security culture and training. Technical controls are only as effective as the people who interact with them. Privileged users should receive targeted training on recognizing phishing attempts, handling credentials securely, and understanding the rationale behind access restrictions. An organization that deploys sophisticated PAM tooling but neglects to educate its administrators risks undermining its own defenses through human error.

Compliance considerations add urgency to this work. Frameworks such as NIST SP 800-207, ISO 27001, and regulatory standards like GDPR, NIS2, and PCI DSS all require demonstrable controls over privileged access. Automated audit logging, which PAM platforms can generate natively and forward to SIEM systems, directly supports compliance reporting and reduces the manual burden on security and legal teams.

Toward a continuous security discipline

The convergence of PAM and Zero Trust is not a one-time project with a defined endpoint. It is an ongoing operational discipline that must evolve in response to new threats, new technologies, and changes in organizational structure. As cloud-native architectures, containerized workloads, and AI-driven automation continue to reshape enterprise IT, the definition of what constitutes a “privileged account” will keep expanding, and so must the controls that govern it.

Organizations that treat PAM and Zero Trust as a living practice, continuously auditing their identity landscape, adapting policies to emerging risks, and investing in both technology and people, will find themselves significantly better positioned against attackers and in front of regulators. Those that treat it as a checkbox exercise will inevitably discover, often at the worst possible moment, that static defenses cannot withstand a dynamic threat environment.

The timing is significant. As geopolitical tensions continue to shape the digital threat landscape, and as regulations such as NIS2 and DORA push EU organizations toward more structured approaches to cyber risk management, the need for a coherent, institution-wide intelligence model has never been more pressing. The CERT-EU framework responds to this need by introducing structured concepts, consistent scoring, and clearly defined threat taxonomies, all calibrated to the specific context of Union entities.

Formalizing the intelligence process

At its core, the Cyber Threat Intelligence Framework defines the analytical and operational standards that CERT-EU uses across its publications, from individual Cyber Briefs to the annual Threat Landscape Report. The fundamental challenge it addresses is deceptively simple: intelligence is only useful if the people producing it and the people acting on it share the same understanding of what terms mean, how severity is measured, and which threats deserve immediate attention versus those requiring only monitoring.

By codifying definitions, scoring criteria, and classification hierarchies, the framework transforms what might otherwise be a subjective, analyst-dependent process into a repeatable and consistent methodology. Primary Operational Contacts (POCs) and Local Cybersecurity Officers (LCOs) at Union entities can now receive CERT-EU alerts knowing that the underlying assessments have been produced according to a transparent, documented standard, rather than relying on implicit institutional knowledge.

The framework is also conceived as a key enabler of what CERT-EU calls its Full-Spectrum Adversary Approach, an internal model for threat-informed defence that supports holistic modelling of threats across both strategic and technical dimensions. By making this approach explicit and reproducible, the framework strengthens situational awareness and ensures that observations translate into structured data capable of driving faster, more coherent operational responses.

The MAI concept and the ecosystem model

One of the framework’s most significant conceptual contributions is the introduction of the Malicious Activity of Interest (MAI) as the central analytical unit. Rather than focusing exclusively on confirmed incidents, an MAI encompasses a broader range of adversary behaviours: confirmed compromises, but also suspicious intrusion attempts, adversarial infrastructure development, and targeted reconnaissance. This expanded scope is deliberate, acknowledging that in modern threat environments, the early stages of an attack cycle carry intelligence value that should not be discarded before a formal incident has been confirmed.

Equally important is the framework’s ecosystem model. CERT-EU does not limit its analytical lens to direct attacks on EU institutions. Instead, it considers the broader environment in which Union entities operate: the countries in which they are active, the sectors they belong to, the software and services they rely on, and the supply chains that underpin their operations. This perspective reflects a crucial insight: a threat does not need to directly target an institution to be operationally relevant. A compromised supplier, a widely exploited vulnerability in commercial software used across EU bodies, or a campaign targeting a sector adjacent to Union entities can all carry systemic implications.

The ecosystem model translates into a more nuanced approach to threat relevance. When CERT-EU analysts assess an MAI, they consider not only whether Union entities are directly targeted, but also how many elements of the ecosystem are affected, and how those effects might cascade. A threat actor whose activity spans multiple ecosystem components will be rated more severely than one whose activity is isolated to a single, peripheral element, even if neither has yet caused a confirmed incident at a Union entity.

Threat levels, actor levels, and scoring

The framework introduces two structured scales designed to support consistent prioritization. The threat level scale assesses the criticality and proximity of malicious cyber activity in relation to Union entities: a “High” rating indicates an immediate threat requiring urgent verification and action, “Medium” signals a close threat warranting careful monitoring, and “Low” describes distant or indirect threats with no immediately identified link to Union entities. These levels are applied particularly in the Threat Alerts that CERT-EU provides to its constituents, guiding the urgency and scope of recommended mitigations.

Alongside this, a threat actor level scale classifies adversaries based on their observed behaviour during a defined period of interest. A “Critical” actor is one that has caused at least one significant incident directly affecting Union entities; a “High” actor has been responsible for a qualifying MAI that did not reach the threshold of a significant incident; “Medium” and “Low” actors are distinguished by the breadth of ecosystem elements their activity has touched. This granularity allows decision-makers to contextualize alerts within a broader picture of adversary behaviour over time, rather than reacting to isolated events without context.

Complementing these scales, the framework defines a scoring mechanism for both adversaries and mitigations. The threat score is driven by five components: occurrences, targeting, severity, time period, and a decay factor that progressively reduces the weight of older activity. The mitigation scoring draws on a formula that incorporates the coverage of adversary techniques by available controls, the number of initial access vectors addressed, and alignment with the Essential Eight baseline practices, providing a quantitative basis for defensive planning and resource allocation that goes well beyond intuition-based prioritization.

Standards and a European approach

A defining characteristic of the CERT-EU framework is its deliberate integration of established international standards rather than the development of new parallel ones. For the classification of adversary tactics, techniques, and procedures (TTPs), the framework adopts the MITRE ATT&CK knowledge base, a widely used, behaviour-based taxonomy that links observable adversary actions to known techniques, making threat-hunting and prioritized mitigation systematic and repeatable for analysts and defenders alike.

For the assessment of source reliability and information credibility, the framework employs the Admiralty Code, a NATO-standard system that evaluates these two dimensions independently. Source reliability is rated from A (completely reliable) to F (unreliable or untested), while information credibility runs from 1 (confirmed by multiple sources) to 6 (cannot be judged). Crucially, CERT-EU only uses intelligence that meets a specific threshold (A1, A2, B1, or B2 combinations), ensuring that CTI products are grounded in information from sources with a demonstrated track record and with sufficient corroboration or plausibility.

On the question of attribution, the framework adopts a strictly technical stance. CERT-EU does not attribute activity to states or organizations, focusing instead on identifying threat actors through observable technical indicators such as TTPs, infrastructure overlaps, malware artefacts, and targeting patterns. When attribution to a known threat actor proves impossible, the framework designates an Unattributed Threat Actor (UTA) with a numeric suffix (for example, UTA-53), which can later be merged with a known actor or another UTA as additional evidence emerges. This approach, consistent with the best practices promoted by the FIRST community for CTI reporting, ensures that attribution claims remain defensible, evidence-based, and revisable as the analytical picture develops.

A living document for a changing landscape

CERT-EU has explicitly designed the framework as a dynamic document rather than a static reference. The threat environment changes constantly: new geopolitical pressures emerge, technologies evolve, and regulatory frameworks are updated. The Cyber Threat Intelligence Framework is intended to evolve in step with these shifts, and the organization has published it under TLP:CLEAR precisely to invite feedback from peers and cybersecurity professionals across the broader community. This openness to external input is itself a statement of intent: effective threat intelligence is a collective endeavour, not a closed institutional exercise.

The implications of the framework extend well beyond the walls of EU institutions. National administrations, public bodies, and private organizations that work in cooperation with Union entities, including those already engaged in information-sharing initiatives coordinated through ENISA, now have a shared reference point for aligning their own intelligence processes. Not by replacing their existing frameworks, but by adopting compatible terminology, confidence scales, and scoring approaches that enable genuine interoperability. In a landscape where cyber threats routinely cross organizational and national boundaries, this kind of methodological alignment is a prerequisite for effective collective defence and for the shared situational awareness that complex, interconnected environments increasingly demand.

On February 19, 2026, Anthropic unveiled Claude Code Security, a new capability integrated into its Claude Code platform, and the cybersecurity industry felt the tremor almost immediately. CrowdStrike saw its stock drop nearly 8% in the hours following the announcement, while Cloudflare shed just over 8%. These are not modest corrections; they signal a market recalibration, a repricing of assumptions that had underpinned the sector for years. Whether or not AI-native security tools will actually replace traditional vendors remains an open question, but the market voted swiftly, and it voted with conviction.

The drop was not driven by panic or speculation alone. Investors and analysts grasped the structural implication behind the launch: a reasoning-based security scanner, built directly into a developer workflow tool used by thousands of engineering teams worldwide, could compress the need for dedicated third-party security products in ways that have no real historical precedent. For the first time, frontier-level security analysis was being packaged not as a standalone enterprise product requiring dedicated procurement, integration, and training cycles, but as a feature embedded in the environment where code is actually written.

How Claude Code Security actually works

What distinguishes Claude Code Security from conventional scanning tools is its departure from rule-based pattern recognition. Traditional static analysis tools work by matching code against a catalogue of known vulnerability signatures. They are fast, consistent, and by definition blind to anything outside their rulebook. Claude Code Security takes a fundamentally different approach: it reads a codebase the way a senior security researcher would, understanding how individual components interact, tracing data flows across the application, and flagging vulnerabilities that emerge from context rather than from a known fingerprint.

Each finding goes through what Anthropic calls a multi-stage verification process, designed to filter out false positives before results ever reach a human analyst. Identified vulnerabilities are assigned severity ratings to help teams prioritize, and each issue also carries a confidence score, an honest acknowledgment that even reasoning-based systems can be uncertain. Critically, nothing in the system applies changes automatically. Patches are suggested, reviewed on a dedicated dashboard, and approved by developers, keeping a human firmly in the loop. This human-in-the-loop design is not a limitation but a deliberate principle: the tool is built to augment decision-making, not replace it.

This is not theoretical capability. Using Claude Opus 4.6, Anthropic’s internal security team found over 500 vulnerabilities in production open-source codebases, bugs that had gone undetected for decades despite years of expert review. The tool is currently available in limited research preview for Enterprise and Team customers, with an expedited, complimentary access path for teams managing open-source repositories.

The structural obsolescence of the old model

The market reaction made headlines, but the deeper story is structural. For years, enterprise security has operated on a model essentially designed for a slower world: periodic scans scheduled weeks apart, vulnerability backlogs stretching into hundreds of unresolved items, and exhausting cross-functional negotiations over which risks deserved immediate attention and which could be deferred. The irony is that these practices never truly managed risk; they managed the illusion of managing risk. Security teams spent enormous energy producing reports that documented exposure without meaningfully reducing it.

A World Economic Forum study from 2025 found that 88% of security teams reported significant time savings through AI-assisted operations. AI-powered penetration testing now runs approximately 80 times faster than traditional manual assessments, with an 80% reduction in remediation time for identified vulnerabilities. These are not incremental improvements; they represent a fundamental shift in what security teams can realistically accomplish per unit of time, and the gap between organizations that have embraced this shift and those that have not is widening every quarter.

The old model made sense when threat actors also operated slowly, when the window between vulnerability disclosure and active exploitation was measured in months rather than hours. That window has collapsed. Attackers now leverage the same AI tools that defenders are only beginning to adopt, automating reconnaissance, payload generation, and lateral movement at a speed that periodic scanning simply cannot match. The asymmetry has become untenable, and the organizations still relying on legacy processes are not managing their exposure; they are simply choosing not to look.

A competitive landscape in motion

Anthropic is not operating in isolation. The AI-powered security space is becoming crowded with credible players, each approaching the problem from a different angle. OpenAI began beta testing a tool called Aardvark in late 2025, an autonomous security researcher built on GPT-5, signaling that the two leading AI labs are now in direct competition in the security domain. Meanwhile, the broader market for AI-native security tools is expanding rapidly, with 97% of organizations reportedly considering AI adoption in penetration testing workflows.

Traditional vendors are not standing still. CrowdStrike has accelerated investment in its Charlotte AI assistant, integrating generative capabilities into its Falcon platform. Palo Alto Networks has expanded its Cortex XSIAM suite with AI-driven threat detection, while Fortinet has deepened its use of machine learning across its Security Fabric. Yet these efforts are largely retrofits, AI capabilities layered on top of architectures designed for a pre-AI era, rather than ground-up rethinks of the security model itself.

This convergence of capability and demand is reshaping how security is purchased, staffed, and integrated into development pipelines. The traditional model of security as an external validation gate, a checkpoint imposed on engineering at the end of a release cycle, is giving way to something more continuous and embedded. Claude Code Security, deployed directly inside a developer’s coding environment, represents a logical endpoint of this shift: security that travels with the code from the moment it is written, rather than arriving after the fact to report on the damage.

What it does not cover: runtime behavior

It is worth noting, however, that the current version does not test runtime behavior. It cannot send requests through an API stack, validate how authentication middleware chains under real conditions, or confirm whether a finding is exploitable in a live environment. Those classes of vulnerabilities, the ones most likely to appear in actual incident reports, only manifest at runtime. A mature AppSec program will therefore need to instrument both code-level reasoning and runtime validation in parallel, not treat one as a substitute for the other.

A reset, not an extinction

None of this means that the expertise, judgment, and creativity of skilled security professionals becomes obsolete. What it means is that the definition of what skilled looks like is shifting. The analyst who spent most of their working day triaging alert queues and writing remediation tickets is looking at a radically different role profile than the one who knows how to configure, interrogate, and challenge an AI-assisted security system effectively. These are not lesser skills, and the transition may lead to work that is both more demanding and more genuinely impactful.

What is ending is the institutional inertia that allowed security to remain expensive, slow, and operationally noisy without accountability. The cybersecurity sector is entering a transformation phase: faster identification of real vulnerabilities, reduced operational noise, tighter integration with development workflows, and transparent confidence scoring are not aspirations for a distant future. They are capabilities available, in preview, today. The tools now emerging do not diminish domain expertise; they amplify it, provided that expertise is applied to the right problems. The challenge is identifying which problems those are before the competitive landscape makes that choice for you.

How ClickFix works: anatomy of deception

ClickFix attacks follow a deceptively simple but psychologically effective pattern. The attacker lures a target to a malicious or compromised page, which presents a fake error message or a fraudulent CAPTCHA verification prompt. The victim is then instructed to open the Windows Run dialog (Win+R), paste a command that has already been silently loaded onto their clipboard by the page, and press Enter. That command, typically a PowerShell invocation, initiates a chain of downloads that ultimately installs an infostealer or a remote access trojan on the system.

What makes this technique especially insidious is its exploitation of the human element rather than any technical vulnerability: no zero-day exploit is required. The attacker simply convinces the user to become an unwitting accomplice in their own compromise. Proofpoint documented an early large-scale campaign in which the technique impacted at least 300 organizations globally, with fake reCAPTCHA messages used to obscure the true nature of the pasted command from the Windows Run dialog. Since then, researchers have reported a surge of over 500% in observed attacks throughout 2025, with threat actors continuously refining both the social lures and the technical delivery mechanisms.

Microsoft Defender researchers observed attackers using yet another evasion approach to the ClickFix technique: Asking targets to run a command that executes a custom DNS lookup and parses the `Name:` response to receive the next-stage payload for execution. pic.twitter.com/NFbv1DJsXn

— Microsoft Threat Intelligence (@MsftSecIntel) February 13, 2026

The range of payloads delivered through ClickFix has grown steadily. Security teams have documented the distribution of Lumma Stealer, StealC, the Amatera infostealer, and various remote access trojans, all delivered through the same core mechanism of clipboard injection followed by manual command execution. This architectural simplicity is precisely what makes the technique so durable: it does not depend on a specific vulnerability, browser version, or operating system configuration, but rather on the consistent reliability of human compliance.

The DNS variant: nslookup as a weapon

The most technically significant evolution of ClickFix was disclosed by Microsoft Threat Intelligence in February 2026: a variant that abuses the nslookup command to retrieve malicious payloads through DNS responses rather than conventional HTTP requests. Victims are instructed to execute a command through the Windows Run dialog that performs a DNS lookup against a hard-coded external DNS server under the attacker’s control. The malicious PowerShell script is embedded directly within the Name: field of the DNS response, parsed from the standard nslookup output, and immediately executed on the victim’s machine.

As BleepingComputer noted in its reporting, this represents the first known use of DNS as a delivery channel in ClickFix campaigns. The approach provides a critical evasion advantage: DNS traffic is ubiquitous on enterprise networks and rarely subject to the same level of inspection as HTTP or HTTPS traffic. By blending malicious activity into standard DNS queries, attackers can bypass web-based detection mechanisms, proxies, and content filtering solutions that would otherwise intercept a traditional download request. The final payload delivered in the observed campaign is ModeloRAT, a remote access trojan that establishes persistent control over the compromised system by creating a MonitoringService.lnk shortcut in the Windows startup folder to survive reboots.

The Microsoft research team described this approach as using DNS as a lightweight staging and signaling channel, which not only reduces the attacker’s dependency on traditional web infrastructure but also introduces an additional validation layer before the second-stage payload is executed. The initial command runs through cmd.exe and directs the DNS lookup toward an attacker-controlled resolver rather than the system’s default one, a detail that further complicates detection for security tools that rely on monitoring communications with known malicious IP addresses. This architectural choice makes campaigns built on this technique significantly more resilient to takedowns and harder to attribute through conventional network forensics.

Google Ads and Claude artifacts: trust as a weapon

While the DNS variant targets Windows environments with technical precision, a parallel campaign documented in February 2026 exploits entirely different vectors to attack macOS users: Google-sponsored search results and public artifacts generated by Anthropic’s Claude large language model. In this campaign, threat actors create publicly accessible Claude artifacts, pieces of content published directly on the claude.ai domain, containing ClickFix instructions disguised as legitimate technical guides. These guides prompt users to open a terminal and execute shell commands, replicating the same psychological manipulation used in the Windows variant but adapted to macOS shell syntax.

The attack’s reach is dramatically amplified through targeted Google Ads that promote these malicious artifacts in search results. As security researchers observed, the ads display the real, recognized claude.ai domain rather than a spoofed or typosquatted address. Clicking the ad leads to a genuine Claude page, not a phishing replica. This combination, a trusted platform combined with sponsored visibility in search results for specific technical queries, creates a near-perfect trust signal for technically inclined users who might otherwise recognize more conventional phishing attempts. A single malicious Claude artifact accumulated over 15,000 views before being identified, according to Rescana researchers, while a second variant distributed through Evernote links pushed the total exposure well beyond 10,000 additional users. The malware delivered to macOS victims includes Atomic Stealer and MacSync Stealer, tools designed to extract credentials, session tokens, browser data, and cryptocurrency wallet contents.

The use of Google Ads in this campaign is particularly noteworthy from a security architecture perspective. Ads can be granularly configured to target users by geographic region, device type, and even the specific email domains of an organization, meaning attackers can tailor the delivery to reach high-value targets with surgical precision while staying within the policy boundaries of the advertising platform long enough to reach a significant victim pool.

A cross-platform threat in rapid evolution

ClickFix’s adaptability is what distinguishes it from more static attack frameworks. The technique has demonstrated a consistent ability to repurpose whatever legitimate infrastructure is currently trusted by target demographics. A variation of the Claude-based campaign stages ClickFix instructions on Evernote links distributed through sponsored results, demonstrating the attackers’ willingness to rotate infrastructure across multiple trusted platforms to maintain campaign longevity. The Center for Internet Security has formally characterized ClickFix as an adaptive social engineering technique, precisely because of this capacity to integrate seamlessly into the evolving digital trust landscape rather than relying on fixed infrastructure.

Kaspersky data indicates that campaigns deploying RenEngine Loader through ClickFix have affected users across Russia, Brazil, Turkey, Spain, Germany, Mexico, Algeria, Egypt, Italy, and France since March 2025, confirming that this is a globally distributed threat with no effective geographic boundary. Further observed variants include a ClearFake campaign that uses fake CAPTCHA lures on compromised WordPress sites to deploy Lumma Stealer, and an email phishing variant that embeds ClickFix instructions within malicious SVG files contained in password-protected ZIP archives, each iteration testing the limits of what detection systems can reliably flag as malicious behavior.

Detecting and mitigating ClickFix attacks

The fundamental challenge in defending against ClickFix lies in its intentional abuse of legitimate user actions and trusted infrastructure. Traditional endpoint detection products may not flag the execution of nslookup or PowerShell as intrinsically malicious, since both are standard system utilities with countless legitimate uses. Security teams should prioritize behavioral monitoring rules that detect anomalous execution patterns, such as nslookup invocations that query non-standard external DNS servers, or PowerShell processes spawned directly from the Windows Run dialog rather than from scheduled tasks or software installers.

From a user awareness perspective, organizations should incorporate ClickFix-specific scenarios into their security training programs, emphasizing the categorical principle that no legitimate service will ever ask a user to manually open a Run dialog, paste commands from a CAPTCHA page, or execute shell instructions copied from a website. Network-level controls, including DNS filtering solutions and policies that restrict outbound DNS queries to unauthorized external resolvers, can significantly reduce the attack surface for the DNS-based variant. For macOS environments, endpoint policies that restrict execution of unsigned shell scripts initiated from browser sessions provide a meaningful additional layer of defense against campaigns that weaponize trusted AI platforms as delivery surfaces.

The broader lesson ClickFix offers is one that extends beyond any single technique or payload family: the security perimeter is increasingly defined by user behavior rather than network topology. As threat actors continue to exploit institutional trust in platforms like Google, Claude, and Evernote, security architectures that focus exclusively on technical controls without addressing the human decision layer will find themselves consistently one step behind.

IoCs

IoCs can be found in a curated STIX 2.1 format at this link.

Between the night of February 1 and February 2, 2026, Sapienza University of Rome experienced something far more serious than a routine IT outage. What struck its campus was a full digital blackout that simultaneously knocked out portals, internal networks, and administrative services, forcing one of Europe’s largest universities into an improvised return to analogue operations. Students found themselves queuing at physical info points, exams continued but grade recording stalled, and administrative deadlines were pushed back as the institution scrambled to contain the damage.

At the heart of the crisis was Infostud, the university’s integrated platform for exam bookings, academic records, payments, and certifications. When Infostud went dark, it triggered a cascade of failures across every service that depended on it, including internal email systems and real-time administrative workflows. The suspension of digital operations was not merely inconvenient: it represented a complete loss of control over processes that, by design, are supposed to be resilient and independently verifiable.

According to reporting by Blasting News, the attack was carried out using the ransomware BabLock, also known as Rorschach, a sophisticated piece of malware first identified in 2023. The malware, attributed to a group operating under the signature Femwar02, is built from code fragments derived from Babuk, LockBit v2.0, and DarkSide, making it particularly fast at encrypting files and difficult to contain once deployed. The attackers are believed to have exploited technical vulnerabilities or a compromised administrator account to gain initial access to the university’s network.

BabLock, bitcoin and the logic of extortion

What transformed a technical incident into a political case was the mechanism of extortion that followed the breach. Consistent with the BabLock playbook, the attackers left instructions for administrators and initiated a negotiation over decryption keys, reportedly demanding up to one million dollars in bitcoin with a 72-hour ultimatum and the explicit threat of publishing exfiltrated data if the ransom went unpaid. The countdown timer, a standard feature of modern ransomware campaigns, is designed to maximize pressure and minimize the institution’s room for deliberation.

The reputational damage extended beyond the technical disruption. On dark web circuits accessible via Tor, offers appeared claiming to sell academic documents attributed to Sapienza, complete with packages mimicking the university’s official identity. Whether these listings were based on actual exfiltrated data or were opportunistic fraud riding the media wave, the effect was identical: the credibility of a public institution was put up for sale. When someone attempts to monetize your identity, the attack is no longer about data alone. It becomes an assault on trust and authority, the two foundations that allow a state institution to function.

The restoration process, when it arrived, involved forensic cleanup, backup validation, and staged service reactivation. But even as Infostud came back online and the university moved toward normal operations, a critical question remained unanswered: what data was actually exfiltrated, in what volume, and what are the potential future uses? Operational damage ends when you restart your systems; strategic damage ends only when you know precisely what left your digital house.

The Viminale breach: 5,000 Digos agents exposed

The second incident is of an entirely different magnitude. A group of hackers linked to Chinese intelligence managed to penetrate the network of the Viminale, Italy’s Ministry of the Interior, and extract files containing the identities, roles, and operational locations of approximately 5,000 agents belonging to Digos (Divisione Investigazioni Generali e Operazioni Speciali). As Euronews reported citing La Repubblica, the division targeted is responsible for counterterrorism surveillance, monitoring of foreign communities, and tracking of dissidents from Beijing who have sought refuge in Italy.

The intrusion is believed to have taken place between 2024 and 2025, and was described by investigators as “surgical”: not an attack aimed at disruption or sabotage, but a targeted exfiltration of high-value operational intelligence. This distinction carries real weight. A noisy attack, one that crashes systems or wipes data, is visible, measurable, and declarable. A silent exfiltration often surfaces only months later, and by then the questions multiply: how long did the adversary have access, how many times did they return, and in what ways is the extracted information already being exploited?

The data extracted goes far beyond a staff directory. It provides a map of investigative priorities, revealing which officers are assigned to the most sensitive operations. For Beijing, having that kind of visibility into Italy’s internal security apparatus is worth considerably more than any conventional act of sabotage. If those files include information on officers involved in tracking Chinese dissidents living in Italy, the implications extend to real people whose safety depends on their cases remaining confidential.

The Chinese shadow and the political trap

The Viminale breach does not occur in a political vacuum. In 2024, Interior Minister Matteo Piantedosi traveled to Beijing and met with his counterpart Wang Xiaohong to establish a three-year cooperation plan covering drug trafficking, cybercrime, human trafficking, and organized crime. In a development described as historically significant, China responded, for the first time, to a formal rogatory request from the Prato prosecutor’s office led by Luca Tescaroli, which was investigating the exploitation of workers within Prato’s textile district and its surrounding criminal networks.

The juxtaposition is uncomfortable. While Italy was attempting to build an operational bridge with Beijing to combat transnational crime, actors linked to Chinese intelligence were inside the Viminale’s systems, mapping precisely the people responsible for those investigations. The two timelines overlap in a way that is difficult to dismiss as coincidence. Every diplomatic opening, if not backed by genuine technical security, can become a strategic asset for an adversary with different objectives. Following the discovery of the intrusion, Italian public security authorities reportedly severed all direct operational collaboration with Chinese counterparts, a decision that reflects how seriously the damage was assessed at the highest levels.

This is not the first time Italy has underestimated the information risk embedded in cooperative arrangements. During the COVID pandemic, Russian military medical teams worked inside Italian hospitals, gaining access to structures and information flows at a moment of acute institutional vulnerability. The lesson that should have been drawn then, that every access point is a potential collection vector regardless of the diplomatic context, was apparently not absorbed deeply enough into the country’s security culture.

Rules for others: the compliance paradox

Both incidents land at a specific and consequential moment in Italy’s regulatory calendar. Legislative Decree 138/2024, which transposed the NIS2 Directive into Italian law, entered into force on October 16, 2024. The measure imposes structured obligations on essential and important entities across energy, transport, healthcare, finance, public administration, and digital infrastructure, covering risk management, incident reporting, business continuity, supply chain security, and executive accountability. By April 2025, ACN (Agenzia per la Cybersicurezza Nazionale) was required to publish minimum security measures; full compliance with advanced requirements is expected by October 2026.

For private organizations, NIS2 means audits, mandatory role designations, investment in security infrastructure, incident notification within 24 to 72 hours, and direct liability for senior leadership. The compliance burden is real, and for many smaller entities in critical sectors it represents a significant operational cost. What makes the picture so troubling is the contrast: the same state that demands this discipline from its private sector is currently managing public institutions that failed to protect the Ministry of the Interior and one of the country’s flagship universities within the same fifteen-day window.

NIS2 is not a compliance logo to display at conferences. It is a commitment. It demands that incidents no longer be treated as confidential embarrassments, that security be demonstrated rather than declared, and that governance failures carry consequences. When the public administration itself provides the clearest examples of what non-compliance looks like in practice, the regulatory architecture risks becoming an asymmetric burden: demanding from the outside what it cannot enforce from within. The credibility of ACN, the agency charged with supervising Italy’s national cyber perimeter, rests in part on its capacity to hold public institutions to the same standards it imposes on the private sector. Two incidents in fifteen days suggest that the distance between the written perimeter and the real one remains dangerously wide.