Steal an agent login and a partner login. Walk internal French tax systems. Headlines still blame the citizen portal.
According to BleepingComputer, France’s Direction générale des Finances publiques (DGFiP), under the Ministry of the Economy and Finance, confirmed unauthorized access after ZeroBytes listed a stolen database for sale on PwnForums on 12 August 2026. Official investigation and disclosure followed. Ministry follow-up figures landed around 17 August 2026. Usurped identifiers of an internal DGFiP agent and an authorized third party authenticated to internal tax and cadastral systems in June and July 2026. Reference tax income, family quotients, withholding rates, business names, SIREN numbers, and cadastral property records for 678,000 individuals and professionals left through those sessions.
ZeroBytes claimed an MFA bypass. Treat that as an attacker line until a regulator documents it. What needs no invention: workforce and partner identities that can mint trusted sessions with transferable secrets.
What the DGFiP breach actually used for entry
The confirmed entry path was identity usurpation on workforce and partner channels. Not a smash-and-grab against citizen tax portals. Officials stated that login identifiers of an internal DGFiP agent and an authorized third party were abused. ZeroBytes claimed those credentials, combined with an MFA bypass, allowed authentication to succeed and persist. Ministry statements confirm the usurpation. They do not verify how any second factor was handled.
Once those usurped identities authenticated, the damage path was live use of internal tax and cadastral systems. According to the French Finance Ministry and DGFiP, quoted via BleepingComputer, prior to interruption those access points had been used to consult and extract data concerning 678,000 individuals and professionals. The same disclosures are explicit on a point headlines often blur: online accounts of individual and professional users were not compromised, and user IDs and passwords were not compromised.
Larger SPDC panel figures and "still logged in" boasts remain attacker statements. Confirmed ministry impact stays at 678,000. Abused access was interrupted, sensitive access shut down, and abused accounts suspended after detection. Adjacent French public-sector incidents named in the same reporting cycle (France Travail, FICOBA, France Titres / ANTS) are news-cycle context only. No proven operational link to DGFiP is established in the public sources used here.
For the attack-side walkthrough, see the related post on legacymfa.sucks: how usurped DGFiP agent and third-party logins opened internal tax systems.
Why transferable agent and partner factors still mint sessions
Initial access is the credential surface. Stolen or usurped workforce and partner login identifiers were enough, in the attacker’s telling with an MFA bypass claim, to complete interactive authentication to internal systems. Officials confirm the identity usurpation. They do not confirm the second-factor path. The operational fact still stands: an outsider completed login as an agent and as an authorized third party and kept working until defenders interrupted those paths. Interactive trust in those identifiers was the hinge.
Whatever sat on those accounts, the login ceremony still completed for someone who was not the legitimate holder. Public detail does not say whether a password was replayed alone, a second factor was completed by the wrong person, or another path was used. Agent and third-party identifiers remained usable for interactive authentication. Transferable secrets (passwords, codes, approvals, recovery channels) are the class of factors that make that usurpation profitable.
Data access is post-authentication use. After authentication succeeded, the live sessions were used to consult and extract records. No separate cookie-stealing malware path, forged federation assertion, or OAuth consent scam is described in public reporting. At that stage the backends did what authenticated users are allowed to do. No login control revokes a session that already exists and is busily querying tax and cadastral data. Prevention has to happen before that point. Detection, account suspension, and access shutdown are what limited further damage after the fact.
| Phase | What was abused | Does login redesign help? |
|---|---|---|
| Initial access | Usurped agent and third-party identifiers | Yes: stop the session from being minted |
| Data access | Live authenticated queries and extraction | No: auth already succeeded |
| Consumer portals | Not compromised per ministry | N/A for this path |
Two bad habits die here. One is assuming every government data leak is "the citizen portal got stuffed." The ministry explicitly said user-facing accounts and passwords were not the prize. The other is treating an unverified MFA bypass claim as a named technique class you can patch by buying one gadget. You cannot inventory a method the victim has not documented. You can inventory whether agent and partner logins still depend on transferable secrets, whether third-party access is over-privileged for bulk consult-and-export, and whether authorized partner accounts get the same scrutiny as staff.
How phishing-proof MFA 2.0 stops usurped IDs from minting the session
For the credential phase, the architectural answer is prevention, not cleverer detection after a trusted session already exists. Prevention matters more than detection when the question is whether a stolen identifier can complete login at all.
Device-bound, public-key authentication changes the surface in a concrete way. The private key never leaves the enrolled hardware. The server stores only public keys. There is no central password or OTP seed store that is useful to steal and replay. Each authentication is a fresh, origin-bound signature. An attacker who holds a usurped username, a password string, or a one-time code still cannot produce the signature that a phishing-proof identity provider demands from the enrolled device. Same-device proof means the ceremony does not depend on a second channel an outsider can intercept or socially engineer in parallel.
That is why MFA 2.0 fits full-lifecycle coverage: it is phishing-proof across registration, device onboarding, authorisation, authentication, and decommissioning when no phishable factor is reintroduced at those stages. Against a DGFiP-style workforce and partner path, the honest claim is scoped:
- In scope for prevention: minting a new trusted interactive session with usurped agent or third-party identifiers when the only material the attacker holds is transferable secrets.
- Out of scope for magic: stopping bulk queries once a legitimate-looking session is already live. Session suspension, least privilege, query monitoring, and rapid account disablement remain necessary residual controls.
- Honesty limit on this incident: public reporting does not document the exact second-factor path. Device-bound design removes the common defeatable factor classes (shared secrets, codes, push approvals). It does not invent a named path the ministry has not published.
Passkeys and FIDO2 are phishing-resistant at the login act. On a generic enterprise identity provider that issues only hardware-bound signatures, the device holds a key pair, the private key never leaves secure hardware, and the signature is bound to the real origin of the login ceremony. An attacker who clones a portal lookalike does not receive a reusable secret the victim types, and cannot complete a valid signature for the legitimate origin from a remote kit. That hardens authentication itself. It is the industry baseline for resisting remote login abuse on workforce apps, including internal tax and cadastral consoles when those apps are fronted by a modern IdP.
Public DGFiP reporting does not describe a helpdesk re-enrollment or recovery-flow takeover as the known entry. The documented hinge is usurped agent and third-party identifiers used for interactive authentication. Still, the ladder matters for any agency copying the wrong lesson. FIDO2 and passkeys are phishing-resistant at login only. If registration, device onboarding, or recovery still accepts email codes, SMS, or push approvals, an attacker who controls those channels can enroll hardware that later looks legitimate. MFA 2.0 is phishing-proof only when no phishable factor appears at any lifecycle stage, including partner onboarding and device replacement. For tax authorities, that means treating authorized third-party enrollment with the same non-phishable bar as staff, not a weaker temporary-access exception. The device-bound architecture only delivers that guarantee when enrollment policy matches the cryptography.
Harvesting a live session from memory on an already-enrolled endpoint takes malware, which is a separate attack with separate controls. MFA 2.0 collapses the remote transferable-factor path. It does not claim to stop every post-auth endpoint compromise. For government tax backends, collapsing the easy remote path is still the highest-leverage change, because that is how this breach class starts.
Partner access needs the same bar as staff. "Authorized third party" is not a reason to leave a weaker factor set on accounts that can consult income, withholding, SIREN, and cadastral stores at scale. If a partner identity can mint the same session power as an internal agent, it needs the same device-bound proof and the same decommissioning discipline when contracts end.
| Control | Against usurped ID login | Against later live-session queries |
|---|---|---|
| Password + classic second factor | Often still completable if secrets move | Does not re-check each query |
| Phishing-resistant passkey at login only | Hardens the login act | Still depends on enrollment hygiene |
| Phishing-proof device-bound lifecycle | No transferable factor to complete remotely | Does not undo an already-good session |
Citizen portal hardening is necessary work. It was not the failure mode officials described here. The sessions that mattered were workforce and partner. Build authentication so those identities cannot be completed with secrets that move. Then a usurped identifier is a ticket to a locked door, not a skeleton key into income and property stores.
If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection.
FAQ
Would phishing-proof MFA 2.0 have stopped the DGFiP data extraction itself?
No. Once usurped agent and third-party identities had already authenticated, live sessions were used to consult and extract records for 678,000 individuals and professionals. Login redesign does not revoke an established session mid-query. The prevention win is upstream: stop stolen identifiers from minting that trusted session in the first place, then rely on suspension and access shutdown if anything still slips through.
What should government agencies change first after a DGFiP-style agent and partner usurpation?
Put device-bound, phishing-proof authentication on every internal agent and authorized third-party path that can reach tax, business registry, or cadastral systems. According to ministry statements via BleepingComputer, consumer portal passwords were not the compromised surface. Align partner enrollment and decommissioning with staff, cut bulk consult privileges, and instrument rapid disablement of abused identities.
Did passkeys alone close every gap illustrated by the DGFiP breach?
No. Passkeys and FIDO2 are phishing-resistant at the login act when private keys stay on device and signatures are origin-bound. If partner or staff enrollment and recovery still use phishable codes or approvals, an attacker can still aim at those lifecycle stages. Full-lifecycle phishing-proof coverage removes phishable factors from registration through decommissioning. Login hardening by itself is not enough.
Was the DGFiP breach a consumer tax-portal password incident?
No. According to the French Finance Ministry and DGFiP via BleepingComputer, online accounts of individual and professional users were not compromised, and user IDs and passwords were not compromised. The breach abused usurped identifiers of an internal agent and an authorized third party against internal systems. Prevention work should prioritize workforce and partner authentication, not only citizen CIAM controls.
How should teams treat ZeroBytes’ MFA bypass claim when designing controls?
Treat it as an attacker assertion that officials have not verified with a product name or method. Design controls that remove transferable factor classes entirely rather than patching one guessed technique. Device-bound signatures stop remote completion when the attacker only holds usurped identifiers and classic secrets. That remains valid whether or not a specific second-factor narrative is ever published.
Updates
2026-02-18: Prior related incident
The late-January 2026 FICOBA disclosure shows usurped civil-servant credentials with inter-ministerial access were sufficient to query France’s national bank-account registry and expose about 1.2 million accounts’ IBAN, identity, and address data.
Source: impots.gouv.fr, FICOBA
