W początkowej wersji NTFS-a, każdy plik i katalog przechowywał swój deskryptor bezpieczeństwa (informację o tym, kto ma do niego jakie prawa) w specjalnym atrybucie. Powodowało to oczywiście bardzo dużą redundancję informacji (często ten sam deskryptor obowiązuje dla danego katalogu wraz ze wszystkimi plikami i katalogami), co w systemach wieloużytkownikowych (np. Windows 2000 Server Terminal Services) powodowało szybkie wyczerpywanie miejsca na dysku.

Dlatego też NTFS od systemu Windows 2000 zawiera specjalny plik metadanych odpowiadających bezpieczeństwu, jakim jest $Secure file. Plik ten zawiera wszystkie deskryptory bezpieczeństwa w systemie (a w związku z tym każdy taki deskryptor jest przechowywany dokładnie raz), poindeksowane na dwa sposoby:

W osobnym atrybucie tego pliku o nazwie $SDS są zawarte same deskryptory bezpieczeństwa:

Figure 11.1. Budowa pliku $Secure file

Kiedy nadajemy plikowi czy katalogowi deskryptor bezpieczeństwa, to NTFS sprawdza, czy ten deskryptor już w systemie istnieje, za pomocą mapowania haszy deskryptorów ($SHD) - przejrzenie to następuje po wszystkich polach o tej samej wartości hasza. Jeżeli taki deskryptor istnieje, to znajdzie się on gdzieś na liście, więc będzie można uzyskać jego unikalny numer i zapisać go w szyfrowanym pkiku czy katalogu. Jeżeli ten deskryptor nie istnieje, to zostanie on dodany do pliku $Secure file, a także zostanie mu przydzielony unikalny w systemie numer.

Kiedy z kolei aplikacja próbuje uzyskać dostęp do pliku czy katalogu, to z atrybutu $STANDARD_INFORMATION z MFT jest pobierany unikalny numer jego deskryptora bezpieczeństwa, a następnie w pliku $Secure file za pomocą mapowania numerów deskryptorów w same deskryptory ($SII) uzyskiwany jest ten deskryptor i jest sprawdzane, czy użytkownik ma prawo do wykonania żądanej akcji na tym pliku czy katalogu. Ostatnie 32 użyte deskryptory (a dokładniej ich unikalne numery) są cache'owane przez NTFS, aby nie trzeba było za każdym razem czytać pliku $Secure file.

Inną ciekawą własnością tego pliku jest to, że NTFS nie usuwa z niego nigdy wpisów, nawet jeżeli już żaden plik ani katalog nie odnosi się do nich. Najczęściej nie powoduje to powiększania się pliku $Secure file zbyt mocno, gdyż przeciętnie istnieje stosunkowo niewiele różnych deskryptorów bezpieczeństwa nawet w systemach wieloużytkownikowych.

W ext3 tego typu kwestie nie są brane pod uwagę. Tam prawa dostępu do pliku przechowuje i-węzeł dyskowy w polu i_mode.