Between June and July 2026, unauthorized access to the information system of the Directorate General of Public Finances was based on the impersonation of credentials belonging to a DGFiP agent and an authorized third party. Before being stopped, these accesses were used to view or extract data concerning approximately 678,000 individuals and professionals. Personal accounts on impots.gouv.fr and taxpayers' passwords were not compromised, according to the official statement from the Ministry of Economy and Finance.
The most instructive point is therefore not that a hacker supposedly 'broke the tax website.' The available information rather indicates that internal credentials were used, which the system could recognize as legitimate. The affected accounts were indeed cut off after the intrusions were detected, but the checks performed at that time did not identify that data had already been taken.
In summary
- Confirmed: two cases of credential impersonation, illegitimate internal access, data extraction or viewing, and about 678,000 individuals and professionals affected.
- Not confirmed: how the credentials were obtained, the exact network path, any possible MFA bypass, and the precise level of privileges reached.
- Security lesson: authenticating an identity is not enough. You must also limit what it can do, monitor its behavior, and be able to revoke all its access quickly.
What exactly happened at the DGFiP?
Status of information as of August 18, 2026
Affected organization
General Directorate of Public Finances (DGFiP)
Intrusion period
June and July 2026
Confirmed initial access
Impersonation of the credentials of a DGFiP agent and an authorized third party
Confirmed impact
Viewing or extraction of data relating to approximately 678,000 individuals and businesses
Officially cited data
Reference tax income, family quotient, withholding tax rate, company name, SIREN, and certain land registry data
Elements not compromised according to the DGFiP
Public Finance user accounts, individual and professional usernames and passwords
Status of the investigation
Ongoing investigations and judicial inquiry; in-depth audit requested from ANSSI
The figure of 678,000 does not correspond to a password leak. However, the exposed tax, family, professional, and property data can make phishing or fraudulent calls much more convincing. Notifications began on August 17 for just over 350,000 individuals, according to the AFP.
Our analysis: the danger starts at authentication
Our analysis of the attack boils down to a very simple sequence, even if all its details have not yet been confirmed by the investigation: a username. A password. A second factor. Then a VPN that opens access to internal tools. On paper, each step seems secure. In practice, as soon as the system recognizes this identity as legitimate, the attacker can access far more information than any administrator would ever want to expose to a compromised account. The problem is therefore not just the entry point: it is the trust and the breadth of rights granted after authentication.
The timeline shows a gap between cutting access and understanding the impact
- June and July 2026: the illegitimate accesses occur. The accounts are suspended as soon as they are detected, without the data theft being identified at that time.
- August 12 and 13: a malicious actor claims the accesses and thorough investigations are launched.
- August 14: the ministry publicly confirms the two intrusions, the use of stolen credentials, and the exposure of around 678,000 individuals and professionals.
- August 17: individual notifications begin and the Prime Minister requests a thorough audit from ANSSI to establish the circumstances and causes of the incident.
- August 18: the exact scope and the technical root cause are still under investigation.
This timeline highlights a key difference: proving that access was revoked does not prove that nothing was extracted beforehand.
What is known about the entry point and what remains unknown
The administration confirms the impersonation of credentials belonging to an agent and an authorized third party, without specifying how they were obtained. Phishing, theft of secrets, workstation compromise, or session hijacking therefore remain hypotheses.
The attacker claims to have gained access to a VPN and an internal search tool. This version is reported by FrenchBreaches and Le Monde, but is not confirmed by Bercy.
It is also not established that a second authentication factor was bypassed. The sequence "username, password, second factor, then VPN" is therefore, as of August 18, a possible scenario but not a proven fact.
- Initial access
What is established: Internal credentials were impersonated
What remains unknown: Method of compromise and possible session theft
- Connection to the IS
What is established: Illegitimate access occurred
What remains unknown: Exact network path, role of the VPN, and status of MFA
- Action on data
What is established: Data was viewed or extracted
What remains unknown: Exact tool, automation, and detailed volume by data type
- Detection and containment
What is established: The accounts used were disabled
What remains unknown: Exact exposure time of each access
- Elevation or lateral movement
What is established: No public evidence allows these to be determined
What remains unknown: Privileges obtained, systems traversed, and any persistence mechanisms
Why can an impersonated identity be mistaken for a legitimate user?
An authentication system first checks whether a person or machine presents the expected elements. If the attacker possesses them or hijacks a validated session, the connection may appear legitimate even though the intent has changed.
MFA, especially when it is phishing-resistant, significantly raises the cost of a compromise. However, it does not determine which data is accessible after login and does not replace least privilege, usage monitoring, or export restrictions.
A VPN protects a channel and opens a network perimeter; it does not automatically constitute a Zero Trust policy. Zero Trust must continue to verify context, limit each resource, and re-evaluate rights during the session. Here, the use of the VPN remains a claim, not an official conclusion.
Which controls could have reduced the probability or impact?
No public source allows us to state that a single product would have prevented this attack. However, several controls could have reduced certain compromise scenarios, shortened exposure time, or limited the accessible volume, provided they were properly deployed.
Cryptographic identity and phishing-resistant passwordless authentication
Intended effect: Reduce the risk of theft and reuse of a password or shared secret
Limitation to keep in mind: Does not alone protect against an already compromised workstation or session
Resource-based authorization and least privilege
Intended effect: Prevent a compromised identity from automatically accessing all tools or data
Limitation to keep in mind: Depends on the accuracy and coverage of the policies
Temporary and contextualized rights
Intended effect: Limit the duration and scope of access for agents, contractors, and third parties
Limitation to keep in mind: Requires operational integration with applications
Detection of abnormal requests or extractions
Intended effect: Detect unusual volume, scraping, or activity inconsistent with the user's mission
Limitation to keep in mind: Requires application logs, appropriate thresholds, and monitoring
Coordinated revocation of accounts, sessions, and rights
Intended effect: Reduce the delay between detection and actual containment
Limitation to keep in mind: Does not allow recovery of data already exfiltrated
Correlation of identity, device, resource, and action
Intended effect: Precisely reconstruct what an identity has done and speed up impact assessment
Limitation to keep in mind: Assumes comprehensive logging and sufficient retention period
What Vaultys could have changed without claiming to have 'prevented the attack'
VaultysID is based on a verifiable identity and passwordless authentication. In a scenario involving theft or sharing of a secret, this approach can reduce exposure to phishing. Since the initial compromise remains unknown, it cannot be claimed that it would have blocked these intrusions.
Discover VaultysID
VaultysHub then governs access: visibility, rights policies, least privilege, revocation, and audit evidence. If properly configured, it could have limited accessible resources, accelerated revocation, and reduced the impact radius.
Discover VaultysHub
The security of an information system never relies on a single barrier. The risk of intrusion—and especially its impact—decreases as the organization combines complementary layers: decentralized identity, passwordless and phishing-resistant multi-factor authentication, Zero Trust policies, ZTNA-type network access, least privilege, continuous monitoring, and audit trails. No single layer is foolproof; their combination prevents a single failure from opening up the entire information system.
This is precisely Vaultys' approach: bringing together in a single platform identity and access management, cryptographic authentication, Zero Trust governance, revocation, connection tracking, and audit evidence generation, with the ability to export logs to existing SIEM tools. Vaultys thus simplifies the deployment and management of these protections, while remaining complementary to endpoint security, DLP, and application controls.
contact us
Eight checks to perform after such an incident
- Inventory internal and third-party accounts with access to sensitive data, with an identified business owner.
- Eliminate shared identities and distinguish between employees, contractors, services, and administrators.
- Test end-to-end revocation of accounts, sessions, network access, applications, and tokens.
- Apply least privilege to search, export, and administration tools.
- Correlate identity, endpoint, network, and application logs to determine which data was actually accessed.
- Alert on abnormal behaviors: volumes, serial access, unusual times, or exports.
- Limit extraction through quotas, minimization of visible data, and application controls.
- Simulate a compromised identity to measure the impact radius and actual containment speed.
The real question: what can a single stolen identity still open?
The DGFiP cyberattack does not prove that MFA, VPN, or any specific technology failed. It shows that an identity recognized as legitimate can become the vehicle for an attack and be cut off only after the data has left.
Zero Trust does not promise that no attack will ever occur. Its goal is to prevent a single compromised access from opening everything, and to make every action attributable, observable, and revocable.
The starting point is a concrete mapping: which identities exist, which resources can they access, and how long does it actually take to cut off all their access?VaultysHub and VaultysID then make it possible to control these identities, manage their access, and quickly revoke them when necessary.