Pentagon DMDC Breach: Nine Months in a File-Sharing System, and the SSNs Were Unencrypted

The interesting part of this breach is not the vulnerability. It is that a file-sharing system held unencrypted Social Security numbers long enough for someone to find the flaw and keep using it. The Defense Manpower Data Center (DMDC), the Pentagon agency that maintains identity and personnel records, has told affected people that unauthorised users accessed files in its file-sharing system between October 2025 and 16 July 2026. Notification letters are dated 18 September.

The technical details are still unpublished. What is known already says a lot about how shared files pile up, and about what to do with sensitive data you have to move between people.

What is confirmed

A Pentagon official confirmed to Federal News Network that a breach of the DMDC information system exposed personal information of more than 3 million people with ties to the US military. SecurityWeek reports the figures as about 2.76 million living individuals and 294,000 deceased people. Reporting on the notification letter describes the same core facts:

The system: a file-sharing system, in which a vulnerability was discovered on 16 July 2026. DMDC says it updated the system to patch it and started incident response.
The window: access by “a small number of unauthorized users” between October 2025 and the discovery date, roughly nine months.
The data: unencrypted Social Security numbers, plus names, dates of birth, contact and demographic details and military occupational specialty.
The response: a year of credit monitoring and identity restoration through IDX, and a statement that there is no indication the information has been misused.

What is not known

The published reporting leaves open the name of the file-sharing product, the nature of the flaw, who the unauthorised users were and how many of them there were. No group has claimed responsibility, and no source we reviewed attributes the activity to anyone.

The number is also not settled. Military Times cites two people familiar with the incident who put the affected population at closer to four million, while the official statements say more than three million. We use the official figure and treat the higher one as an unconfirmed estimate. It is also unclear why the data was stored unencrypted, or why access continued for nine months before discovery. “No indication of misuse” describes what DMDC has seen so far, which is not the same as knowing the data has not been used.

Why a file-sharing system is where this happens

A file-sharing system is built to make things easy to reach. People drop an export in so a colleague can pick it up, and the system is the path of least resistance for anything too big or awkward for email. The trouble is that the same convenience means the files rarely leave. Nobody owns deletion, so a transfer that should have lasted an afternoon becomes a standing archive.

When the flaw is finally found, the exposure is set by what accumulated, not by what was being shared that week. Nine months of access to a system holding full identity records is a very different incident from nine months of access to a system that held last week's transfers.

We are not claiming DMDC's system worked this way. The reporting does not describe its retention practices. The pattern is general, though, and anyone running a shared drive, an SFTP drop or a team folder can test it against their own environment.

Questions worth asking about your own file exchange

What is in it right now? List the files older than 30 days and ask who still needs each one. A shared area with no expiry is an archive whether or not anyone decided that.
Are identifiers stored in the clear? Social Security numbers, national ID numbers, bank details and health records in exported spreadsheets are the worst case. If the file must exist, protect it with encryption whose key does not sit next to it.
Does every transfer have an end date? Set automatic deletion at the system level. Relying on people to clean up is how nine-month exposure windows appear.
Who can see access logs, and does anyone read them? An unauthorised user using the system for months implies that access was normal-looking or nobody was looking. Alert on unusual download volume and on accounts that read files they never wrote.
Can you send less? Most recipients need a few fields, not the full record. Remove identifiers before a file leaves the system that owns them.
Is there a patch owner for the exchange itself? File-transfer tools are internet-facing by design, and they are a recurring target. Put them on the same emergency-patch list as your gateways.

For the people whose data was in it

If you received one of these letters, the concrete steps are the standard ones for a leaked Social Security number. Place a freeze with each of the credit bureaus, which is free and can be lifted temporarily when you need credit. Consider the identity-protection PIN the IRS offers. Review statements for accounts you do not recognise.

Breach notifications are also a reliable template for scammers, because recipients expect a message and expect to act on it. Enrol in the monitoring service by going to the address printed in your letter or published by the agency, not by following a link in an unsolicited email or text, and never give your full Social Security number to someone who contacted you first. Government agencies do not ask for it by return message. We have no evidence of scams targeting this specific notice; this is a general precaution.

Where Secretus fits, and where it does not

Secretus handles a narrow case: a person sending another person a small piece of text that should not linger, such as an identifier, an account number or a credential. In the default mode the secret is encrypted in the browser, the server stores only ciphertext, and the link stops working after the expiry you chose or after it is opened. That makes it a better place for a one-off handover than a shared folder that nobody empties.

It is not a file server, a records system or a data loss prevention tool. It does not replace encryption at rest for a personnel database, retention policy for a shared drive, or patching for the software that exchanges your files. It cannot protect data that has already been copied to a shared folder, and it will not tell you whether your own environment holds another DMDC-sized surprise. The habit worth copying is smaller: send the one value someone needs, let it expire, and keep the full record in the system built to hold it.