FAT and NTFS solve the same problem: tracking which clusters belong to which file. The two filesystems answer it very differently, and the difference is the entire reason modern Windows forensics has the toolkit it does. On FAT, you can often prove a file existed. On NTFS, you can usually prove what was inside it, when it was touched, who linked to it, and what happened to it after.
How FAT works, in one paragraph
FAT keeps a single table where each entry maps one cluster to either the next cluster in the file, an end-of-chain marker, or the value 0 meaning free. A separate directory entry pairs a filename with the first cluster of the file. To read a file, you walk the chain. To delete one, FAT clears every cluster entry in the chain to 0 and replaces the first character of the filename in the directory entry with 0xE5. The data is left behind, but the chain itself is destroyed: you can recover the first cluster and a partial filename, but the linkage to subsequent clusters is gone.
That last sentence is the whole problem with FAT recovery. FAT recovery tools can find file fragments. They cannot reliably reassemble them when the file was fragmented across the disk. Sequential files (cameras, audio recorders writing one big WAV) come back; fragmented files (anything Office, anything written over time, anything on a half-full volume) come back partially if at all.
How NTFS works
NTFS replaces the allocation table with the Master File Table, one file where every other file has at least one 1,024-byte record describing it. Each record is a small container with typed attributes: $STANDARD_INFORMATION, $FILE_NAME, $DATA, $INDEX_ROOT, and the others detailed in the attribute reference.
Critically, $DATA does not point at "the first cluster" and rely on a separate table to chain. It carries a complete runlist: a sequence of (start LCN, length) pairs that covers every fragment of the file. Deleting a file does not break that list. The list lives inside the record, and the record persists until something else claims its slot.
This is the single design decision that changed everything for forensics.
What changes for forensics
Deleted files retain their runlist. Until the MFT slot is reused, you can read the runlist of a deleted file, walk to its clusters (which the allocator may not yet have given out), and reconstruct the data even when the file was heavily fragmented. FAT cannot do this.
Eight timestamps per record, two of them resistant to tampering. $STANDARD_INFORMATION and $FILE_NAME each carry four timestamps. SI moves on every operation; FN is stable after creation. The two sets cross-check each other. See the four MFT timestamps for the timestomping signal this surfaces. FAT carries one creation timestamp, one modified timestamp (in DOS time format, with two-second granularity), and an optional access date. No cross-check, no granularity, no defense against trivial timestomping.
Resident data for small files. Files under roughly 700 bytes of data live entirely inside their MFT record. Recover the record, recover the file, without ever touching the data area. This is how a small text file deleted a month ago and overwritten on the data clusters can still come back intact. See resident data.
Hard links and ADS. A single MFT record can have multiple $FILE_NAME attributes (hard links) and multiple $DATA attributes (the primary stream plus alternate data streams). The forensic evidence from these is rich and FAT has nothing equivalent. ADS is a place attackers stash payloads. Hard links are a way to make the same file appear in multiple directories with different parent references; useful for tracking persistence mechanisms.
Journals. The change journal $UsnJrnl records every metadata operation: create, delete, rename, data overwrite, with timestamps and reasons. $LogFile records transaction-level detail. FAT records neither.
Security descriptors. $Secure holds the ACL store; every file references its ACL by ID. Forensic relevance: you can prove who had access, and when ACLs changed (SetSecurityInfo writes a USN reason of SECURITY_CHANGE). FAT has no concept of per-file permissions.
Reparse points. Symlinks, junctions, mount points, OneDrive placeholders, dedup stubs, and WSL POSIX metadata all live in $REPARSE_POINT attributes. FAT cannot represent any of this; modern Windows features that depend on reparse points simply do not work on FAT volumes.
The aggregate effect: if you have a choice between a FAT image and an NTFS image of the same incident, the NTFS image will almost always answer more questions. Often by an order of magnitude.
Where you still meet FAT
FAT is not dead. You will still encounter it on:
- USB flash drives formatted at the factory (exFAT on larger ones, FAT32 on smaller).
- The EFI system partition on every UEFI Windows install (FAT32, around 100-300 MB, contains the Windows Boot Manager).
- SD cards from cameras, drones, embedded devices.
- Older industrial controllers and a long tail of embedded Linux that still defaults to FAT for removable storage.
- Some Mac-formatted volumes shared with Windows (exFAT).
For OS volumes on any modern Windows machine, you are looking at NTFS. ReFS appears on some Server installations and Storage Spaces but not the boot drive. The artifact you want is $MFT.
exFAT, briefly
exFAT is the in-between case. It is what Microsoft used to replace FAT32 on volumes too large for FAT32's 32 GB practical limit. Modern allocation table with cluster chains, but no journal, no MFT, no ADS, no hard links, no security descriptors. From a forensic perspective it is closer to FAT than to NTFS. You get timestamps (more granular than FAT), you get the cluster chain, and you get the directory entries. You do not get any of the things that make NTFS forensics worthwhile.
When you see exFAT on a removable device that mattered, your tooling shifts: PhotoRec and scalpel for signature carving, fsstat and fls from Sleuth Kit for what little structure exists, and an honest acknowledgment in your report that the artifact set is limited.
A practical consequence
People sometimes ask why their FAT-formatted USB stick yielded so little compared to the NTFS volume from the same incident. The honest answer is structural: the filesystem decided what evidence to leave behind years before the incident happened. Format choice is itself a forensic variable, and somebody used to grabbing artifacts off Windows desktops will be sharply disappointed by an exFAT camera card.
If you control the choice (corporate baseline, lab imaging media), pick NTFS. If you do not (incident response on a target you did not specify), accept the constraints and shift your tooling.
Further reading
- Microsoft, FAT vs NTFS comparison. Official feature matrix.
- Brian Carrier, File System Forensic Analysis. The chapters comparing FAT and NTFS are still the definitive reference.
- The exFAT specification (Microsoft). Worth reading once if you regularly deal with removable media.