Network Access Control to proces wsparty technologią, który ma pomóc organizacjom chcącym rozwiązać problem braku kontroli nad urządzeniami podłączanymi do firmowej sieci. Szczególnie istotne jest to w środowiskach, w których do realizacji zadań zatrudniane są firmy zewnętrzne lub też model biznesowy wymaga angażowania w projekty zespołów pochodzących z wielu organizacji. Już w 2011 firma Aberdeen Group w wynikach swoich badań mówiła, że na 100 pracowników około 27 to kontraktorzy lub pracownicy czasowi. Z kolei 2 z 5 to pracownicy mobilni lub zdalni. Ale powodów, dla których NAC miał i ma rację bytu jest więcej.

Typowym wyzwaniem dla każdej organizacji jest to, że z pomieszczeń ogólnego dostępu czy sali konferencyjnych możliwe jest nawiązanie połączenia z siecią lokalną. Rzecz jasna, nie jest tak, że firmy w ogóle sobie z tym nie radzą. Niemniej jednak zapewnienie jednolitej kontroli nad dostępem do sieci, zwłaszcza w dużych organizacjach, nie jest rzeczą prostą, choćby przez lekko „zaśmiecone” listy dostępowe na przełącznikach, gniazdka, o których nikt nie pamięta itp. Ile razy „na szybko” podłącza się przewody w sali konferencyjnej, a potem nie pamięta się o powrocie do stanu wyjściowego? Do tego dochodzą urządzenia, które wpięte są do sieci – z drukarkami czy telefonami IP na czele.

Remedium na te problemy miała być wymyślona dawno przez Cisco koncepcja technologii NAC. Wówczas chodziło nawet nie tyle o zapanowanie nad urządzeniami, co o dostarczenie mechanizmów, które pozwalałyby ograniczyć ryzyko wpuszczenia zainfekowanej stacji do sieci. Można było zweryfikować, do kogo należy stacja – do sieci wpuszczało się tylko swoje komputery. Żeby taka weryfikacja była możliwa, konieczne było zastosowanie mechanizmów kontrolnych jak najwcześniej, najlepiej w L2, zanim stacja uzyska adres IP. Stąd też pojawił się protokół 802.1x umożliwiający uwierzytelnienie stacji (lub użytkownika), w ramach organizacji TCG (Trusted Computing Group) powstał TNC (Trusted Network Connect), czyli zestaw standardów, który mógłby zostać wykorzystany przez producentów rozwiązań NAC, a IETF (Internet Engineering Task Force) powołał zespół NEA (Network Endpoint Assesment), który opracował szereg dokumentów RFC (5792, 5793, 6876).

Do gry włączył się także Microsoft ze swoją odmianą NAC-a, czyli NAP, choć daje się zauważyć, że przestał ją aktywnie promować. Ta wielostronna aktywność przyniosła z jednej strony wiele dobrego, bo pojawiły się ciekawe pomysły, z drugiej jednak spowodowała, że ostatecznie nie nastąpiła jednomyślność co do uniwersalnego standardu. Niektórzy producenci zupełnie się wyłamali i zaczęli przygotowywać własne propozycje implementacji. Było to jednym z powodów (oprócz trudności w implementacji, braku zgodnego sprzętu, dużego nakładu funduszy i pracy), dla których szał na NAC ostygł. Nie oznacza to jednak, że NAC umarł, a dostawcy porzucili ideę rozwijania tej technologii, o czym za chwilę.