Detection Isn't Containment: What the DGFiP Breach Teaches MSSPs About Session Revocation

What Happened

France's Direction Générale des Finances Publiques, the agency that runs the country's tax administration, spent seven weeks compromised before the intrusion was fully understood, according to reporting on ANSSI's incident report [1][3]. The attacker got in using stolen staff passwords, no exploit chain required, just credentials that worked [1][12]. By the time the breach was contained, data tied to hundreds of thousands of taxpayer and business records had been exposed, with public figures on the affected population ranging from 600,000 to 678,000 depending on the outlet [2][4][7].

ANSSI, France's national cybersecurity agency, published its post-incident report in late September 2026 and the detail that should stop every SOC operator mid-coffee is this: the suspicious activity wasn't missed. It was flagged, twice, by monitoring that was doing its job [5][6][10]. The agency's own security team rotated the compromised credentials after each alert. What they didn't do was terminate the live session tied to those credentials. The attacker kept the session open, kept the access, and kept pulling data for roughly 16 more hours after the second detection [5][6][10].

That is not a detection failure. That is a containment failure wearing a detection failure's reputation.

Why This Is Worse Than 'They Missed It'

There's a certain grim comfort in a breach story where nobody saw anything. It fits the narrative: blind spot, dwell time, lessons learned. The DGFiP case denies you that comfort. The monitoring worked. Someone, somewhere, looked at a login that didn't belong and said "that's wrong," and said it twice. The response to being right was to change the lock on a door the intruder was already standing inside of.

Rotating a password invalidates future logins. It does nothing to a session token that's already been issued and is actively being used. If the attacker authenticated once and is riding an active session, cookie, or OAuth token, a new password is a formality they never have to deal with. ANSSI's analysis points to exactly this gap, alongside broader weaknesses in how the intrusion was structured, reportedly distilled into three core failure points around access control and monitoring depth [17][11]. The attack itself wasn't sophisticated. Reports describe it as persistent rather than advanced, a "peu avancée mais tenace" intrusion that succeeded on patience and gaps, not zero-days [10].

That combination, unsophisticated technique plus sustained access plus a SOC that saw the activity and still couldn't stop it in time, is the part MSSPs should sit with. It means the control gap wasn't visibility. It was authority to act on what was visible.

Detection Without Containment Is Just Expensive Journaling

Here's the uncomfortable framing: an alert that doesn't terminate the thing it alerted on is a very well-documented breach. You'll have excellent logs for the retrospective. The attacker will have your data.

A SOC's job isn't to notice. Noticing is step one of a four-step job. The other three are confirm, contain, and communicate, in that order, and contain has to happen before the shift ends, not after the incident report gets written. If your monitoring stack can detect an anomalous login but your process stops at "email the admin to rotate credentials," you have built a very expensive notification system, not a security operation.

What Real Containment Requires

Three capabilities separate a SOC that watches from a SOC that stops.

Session and token revocation, not just credential rotation. When identity monitoring flags an anomalous login, in Microsoft Entra, Okta, or any federated identity provider, the response has to include killing the active session and any issued tokens, not just forcing a password reset on the account. A revoked password with a live session is a locked front door with the back door propped open.

Cross-tenant IOC correlation. A single suspicious login at a single agency is a data point. The same indicator of compromise, a source IP, a login pattern, a token fingerprint, appearing across multiple monitored environments is a campaign. A SOC watching one tenant in isolation treats the second DGFiP-style detection as a repeat of the first anomaly. A SOC correlating across its full customer base treats it as escalation, because it can see the pattern the single-tenant view can't.

Segmentation enforcement. Containment isn't only an identity action. If the compromised account could reach systems and data far beyond its legitimate scope, the access itself was the design flaw, and no amount of fast credential rotation fixes an account that was over-privileged from day one. Enforcing least privilege and segmenting what a single compromised identity can touch limits the blast radius even when the response to the alert is imperfect.

None of this is exotic. It's the difference between a SOC that generates tickets and one that's authorized, technically and contractually, to act on them.

What Vijilan's Global SOC Does Differently

Vijilan's Global SOC is built around the premise that an alert is the start of a response, not the end of one. Through ThreatRespond™, our Managed XDR service, identity anomalies correlate across the full set of monitored environments, not just the one where the login occurred, so a pattern that would look like an isolated incident in a single-tenant view gets treated with the urgency a campaign deserves. ThreatContain™ is built specifically for the moment this article is about: the gap between "we saw it" and "it stopped," with session termination, token revocation, and isolation actions available to the SOC as part of the response, not as a recommendation sent to a client's inbox to action on their own time.

The DGFiP case is useful precisely because it's not a hypothetical. It's a working example of what happens when monitoring and containment are treated as the same step when they aren't. Detection tells you something is wrong. Containment is the part that actually stops the bleeding, and it has to include killing the session, not just changing the key.

What MSSPs Should Do With This

If you're white-labeling SOC services or running co-managed detection for clients, this is a good week to ask a blunt question internally: when your monitoring flags an anomalous identity event, does your response playbook end at credential rotation, or does it include active session termination? If the answer is the former, you have the DGFiP's exact gap, just waiting for its own version of this headline.

Vijilan works with MSPs, MSSPs, VARs, and distributors to close that gap, and we never compete with our partners for their clients. Whether you need full white-label delivery or a co-managed model layered onto your existing stack, the containment capability is the part worth auditing first.

If you want to talk through what containment actually looks like for your environment, visit /msp. Pricing questions go to /pricing.

Sources: The Hacker News [1], dev.to [2], TechNadu [3], Bitdefender [4], it-connect.tech [5], Hufileaders community [6], BreachHistory [7], ANSSI on X [9], Alliancy [10], Siecle Digital [11], Clubic [12], La Cour Avocat [13], Cyberattaque.org [14], FrenchBreaches [15], KingOfGeek [16], Quasa.io [17].

Frequently asked questions

What actually happened in the DGFiP breach?

An attacker used stolen staff passwords to access France's tax agency systems. The intrusion went undetected in its full scope for seven weeks, and ANSSI's incident report found that monitoring flagged suspicious logins twice, but the response rotated credentials without terminating the active session, allowing exfiltration to continue for roughly 16 more hours.

Why isn't rotating a password enough to stop an active intrusion?

A password reset blocks future logins but does nothing to a session or token that's already been issued and is in active use. If the attacker is riding an existing session, they don't need the old password again, so the session itself has to be terminated, not just the credential.

What's the difference between detection and containment in a SOC context?

Detection identifies that something anomalous is happening. Containment stops it, through actions like session and token revocation, isolating affected systems, and enforcing segmentation so the compromised access can't reach beyond its scope. A SOC that only alerts isn't containing, regardless of how fast the alert fires.

How does Vijilan's SOC handle this differently?

ThreatRespond correlates identity anomalies across the full set of monitored environments to catch campaign-level patterns, and ThreatContain gives the SOC authority to take session termination, token revocation, and isolation actions directly, rather than only recommending them to the client.