November 2026. Control 8.5 (veilige authenticatie) uit Annex A schrijft geen specifieke techniek voor, maar in de praktijk verwacht een auditor multifactor-authenticatie (MFA) op alles wat ertoe doet. Het gaat vaak mis bij de uitzonderingen. Zie ook ons artikel over toegangsbeheer.
Waar MFA in elk geval hoort
Beheerdersaccounts, externe toegang (VPN, remote desktop), e-mail en samenwerkingsplatforms, cloud- en SaaS-diensten met bedrijfsgegevens, en leveranciersaccounts met toegang tot uw omgeving. Begin bij beheerders: dat zijn de accounts met de grootste impact.
Kies de sterkte van de factor
Niet alle MFA is even sterk. Sms-codes zijn zwakker dan app-codes, en phishing-bestendige methoden zoals passkeys of beveiligingssleutels zijn het sterkst. Zie passkeys voor de afwegingen.
Uitzonderingen: leg ze vast
Er zijn systemen waar MFA technisch niet kan, zoals oude applicaties of servicekoppelingen. Documenteer elke uitzondering met reden, eigenaar, compenserende maatregelen (zoals IP-beperking, sterke wachtwoorden en monitoring) en een einddatum of reviewmoment. Een uitzondering zonder vastlegging is een bevinding.
Servicekoppelingen en gedeelde accounts
Gedeelde accounts zijn de klassieke zwakke plek. Vervang ze waar mogelijk door persoonlijke accounts; voor technische accounts gebruikt u geheimen in een kluis, beperkte rechten en logging. Lees ook over het wachtwoordbeleid.
Bewijs voor de auditor
Een rapportage uit uw identiteitsplatform met het percentage accounts met MFA, het beleid, de lijst met uitzonderingen en een voorbeeld van een uitgevoerde review. Dat laat zien dat het niet bij een intentie blijft.