Identiteit is lange tijd de hoeksteen van cybersecurity geweest: verifieer de gebruiker en beveilig de toegang. Maar met de opkomst van professionele dreigingsactoren die AI en geavanceerde phishingkits inzetten, begint deze aanpak te haperen. Identiteit draagt een last waarvoor het oorspronkelijk niet bedoeld was. In omgevingen met SaaS-spreiding, BYOD en hybride werken is een geldig account geen garantie meer voor een veilige verbinding.

Het grootste risico is niet dat authenticatie faalt, maar dat niet de juiste signalen worden gecontroleerd. Zonder realtime controles van het apparaat kan een legitieme login net zo goed een gecompromitteerde sessie zijn. Multi-factor authenticatie (MFA) moest dit gat dichten, maar phishingkits kunnen nu realtime tussen gebruiker en loginportaal zitten, de authenticatie proxien en de sessietoken stelen nadat MFA is geslaagd. De gebruiker doorloopt alle beveiligingschecks, terwijl de aanvaller met de sessietoken wegloopt.

De NIST Special Publication 800-207, de basis voor Zero Trust-architectuur, waarschuwt tegen het vertrouwen op identiteit alleen na een initiële authenticatie. Toegangsbeslissingen moeten ook rekening houden met de beveiligingsstatus van het gebruikte apparaat. In de praktijk behandelen veel organisaties authenticatie nog steeds als een eenmalige controle: identiteit wordt geverifieerd, MFA wordt doorstaan, een sessie start en het vertrouwen blijft gelden tot de token verloopt. Maar een sessietoken in de browser van een aanvaller is niet te onderscheiden van die in de browser van de gebruiker, en traditionele authenticatielogs kunnen dit niet detecteren.

De meeste Zero Trust-implementaties richten zich sterk op identiteit: het versterken van authenticatie, afdwingen van MFA, minder afhankelijkheid van wachtwoorden en risicogebaseerde aanmeldingsbeleid. Apparaatverificatie wordt daarentegen vaak inconsistent toegepast en stopt meestal bij het inloggen of geldt alleen voor browsergebaseerde workflows binnen moderne toegangscontroles. Legacy-protocollen, remote access tools en API-integraties erven vaak impliciet vertrouwen zodra identiteit is vastgesteld. Dit leidt tot een gefragmenteerd model waarin persoonlijke en derdepartijapparaten vaak losjes of helemaal niet worden beheerd. Sessietrust blijft bestaan, ook als de beveiligingsstatus van het apparaat tijdens de sessie verslechtert. Identiteit en endpoint-signalen worden in aparte tools beheerd met beperkte integratie, waardoor toegang zelden opnieuw wordt beoordeeld na het inloggen.

Het apparaat is de andere helft van de oplossing. Een gestolen wachtwoord gebruikt vanaf een door een aanvaller beheerd apparaat mag niet hetzelfde worden behandeld als datzelfde wachtwoord gebruikt vanaf een geregistreerd, versleuteld en compliant bedrijfsapparaat. Apparaatstatus geeft antwoorden op vragen die identiteit niet kan beantwoorden: is het apparaat versleuteld, is endpointbescherming actief en up-to-date, is het besturingssysteem gepatcht, is de configuratie conform beleid en is het hardware dat is goedgekeurd? Cruciaal is dat deze status actueel blijft gedurende de hele sessie, want updates kunnen worden uitgesteld, endpointbescherming uitgeschakeld en ongeautoriseerde software geïnstalleerd. De situatie bij het inloggen is niet per se gelijk aan die na enkele uren gebruik. Continue apparaatverificatie vermindert het risico op misbruik van legitieme sessies aanzienlijk.