Multi-factor authentication voor woningdata en API-toegang

Multi-factor authentication is authenticatie met minimaal twee onafhankelijke factoren. In Nederland gebruikte in 2024 61% van de bedrijven met twee of meer werknemers MFA, tegenover 26% in 2017. Voor woningdata en developer-accounts is MFA daardoor geen extraatje meer, maar een basismaatregel.

Een productteam bouwt vandaag misschien een hypotheekflow, desktop taxatie of portefeuilleanalyse rond API-toegang tot woningkenmerken, transactiedata en energie-informatie. Tegelijk loggen developers in op cloudomgevingen, dashboards en repositories. Eén gestolen wachtwoord kan dan niet alleen een gebruikersaccount raken, maar ook een koppeling met klantdata, taxatie-uitvragen of een productieomgeving.

Voor banken, hypotheekverstrekkers, taxateurs, verzekeraars en softwareleveranciers ligt de juiste vraag daarom niet bij “hebben we MFA?”, maar bij welke factor beschermt welk account, met welke dekking en welk herstelproces? De rest van dit artikel behandelt multi-factor authentication vanuit die architectuurkeuze.

Wat multi-factor authentication is en waarom het ertoe doet

Multi-factor authentication is authenticatie met minstens twee onafhankelijke factoren. Het NCSC onderscheidt drie categorieën: iets wat je weet, iets wat je hebt en iets wat je bent. Een wachtwoord met een authenticatorcode gebruikt bijvoorbeeld kennis en bezit. Een pincode met een hardware key doet hetzelfde. Een wachtwoord met een vingerafdruk combineert kennis en biometrie.

Het NCSC adviseert MFA voor internettoegankelijke accounts, beheeraccounts en essentiële systemen. De reden is direct: als een aanvaller alleen een wachtwoord steelt via phishing of hergebruik, ontbreekt nog steeds de tweede onafhankelijke factor. MFA maakt een gestolen wachtwoord dus minder bruikbaar, al beschermt het niet tegen elke vorm van sessie- of identiteitsmisbruik. Het NCSC legt de technische werking en accountclassificatie van MFA uit.

Waarom woningdata een aantrekkelijk doelwit vormt

Woningmarktorganisaties verwerken meer dan een losse postcode. Denk aan klantdossiers, taxatieaanvragen, objectkenmerken, transacties, energiegegevens, hypotheekproducten en koppelingen met externe datasystemen. Een account bij een makelaarsportaal, taxatieplatform of API-gateway kan toegang geven tot processen die direct samenhangen met kredietbeslissingen, verzekeringsrisico's of portefeuillebeheer.

Credential stuffing gebruikt wachtwoorden die eerder bij andere diensten zijn buitgemaakt. Phishing probeert medewerkers ertoe te bewegen hun inloggegevens op een nagemaakte pagina in te vullen. Sessiemisleiding gaat nog een stap verder, bijvoorbeeld wanneer een aanvaller een geldige sessie of token misbruikt nadat authenticatie al heeft plaatsgevonden.

Architectuurregel: behandel MFA als minimumcontrole voor menselijke toegang tot woningdata, niet als vervanging voor autorisatie, sessiebeheer en monitoring.

Teams die hun toegangsmodel opnieuw ontwerpen, kunnen MFA koppelen aan centrale identity and access management. De uitleg over access control bij Altum AI helpt om authenticatie te onderscheiden van autorisatie, dataminimalisatie en rechten per toepassing. Voor gebruikers die met verschillende zakelijke portalen werken, kan ook een praktische apphaus portaal inloggen gids helpen om het verschil tussen portaaltoegang en aanvullende beveiligingsstappen helder te maken.

Voor woningdata en API-toegang is de conclusie eenvoudig. Een wachtwoord alleen voldoet niet meer als basis voor toegang tot gevoelige systemen.

De Nederlandse adoptie van MFA in cijfers

MFA is in Nederland breed ingevoerd, maar de dekking is niet overal gelijk. Volgens de cybersecuritymonitor van NCSC en CBS steeg het aandeel bedrijven met MFA van 26% in 2017 naar 61% in 2024. Bij bedrijven met 250 of meer werknemers lag het gebruik in 2024 op 97%, terwijl bedrijven met 2 tot 10 werknemers op 57% uitkwamen. De Cybersecuritymonitor 2024 beschrijft deze ontwikkeling bij Nederlandse bedrijven.

De cijfers zeggen niet automatisch dat ieder account, iedere applicatie en ieder proces met een tweede factor is beschermd. Visma meldde dat slechts één op de vier organisaties aangeeft dat 2FA bij iedereen is ingesteld. Dat verschil maakt beleid en uitvoering zichtbaar: een organisatie kan MFA formeel hebben ingevoerd, terwijl serviceaccounts, externe leveranciers, shared accounts of oude applicaties buiten beeld blijven.

De sterke stijging bij bedrijven met 10 tot 50 werknemers, van 29% in 2017 naar 76% in 2024, laat zien dat MFA ook in het mkb snel een standaardmaatregel wordt. De CBS-cijfers over tweefactorauthenticatie bij bedrijven zijn hier samengevat. Gebruik de verschillende bronnen wel zorgvuldig, want publicaties rapporteren niet overal exact dezelfde afbakening of meetperiode.

Wat dit betekent voor de woningmarkt

Woningmarktorganisaties werken vaak met meerdere identiteiten tegelijk. Een medewerker gebruikt een SSO-account, een taxateur een klantportaal, een developer een cloudconsole en een integratie een machinecredential. De adoptiegraad van de organisatie zegt dan weinig over de feitelijke bescherming van de volledige keten.

De bestuurlijke opgave is daarom groter dan een technische configuratie. Maak dekking aantoonbaar per accountklasse, applicatie en leverancier. Leg vast welke accounts MFA gebruiken, welke uitzonderingen bestaan en wie die uitzonderingen periodiek beoordeelt. Dat ondersteunt AVG-verantwoording en sluit aan bij strengere eisen rond digitale weerbaarheid, waaronder NIS2 en DORA.

Typen MFA-factoren naast elkaar

Niet iedere MFA-factor biedt dezelfde bescherming. De keuze moet afhangen van accountwaarde, phishingrisico, werkomgeving, herstelbaarheid en beheerlast. Voor een klantgericht portaal gelden andere eisen dan voor een developer-account met toegang tot productie-API's.

De praktische keuze per account

TOTP is een bruikbaar minimum voor oudere SSO-integraties en applicaties die nog geen WebAuthn ondersteunen. De code komt uit een authenticator-app en is niet afhankelijk van een telecomprovider. De code blijft wel gevoelig voor een phishingflow waarin een aanvaller de gebruiker live door een nagemaakte login leidt.

SMS gebruik je alleen als niets anders haalbaar is. Het werkt voor gebruikers met beperkte technische ondersteuning, maar het beschermt minder goed tegen SIM-jacking en social engineering. Maak voor gevoelige woningdata een migratiepad naar een authenticator-app, passkey of hardware key.

Pushmeldingen passen bij klantgerichte portals en medewerkers die snel tussen systemen wisselen. Zet nummermatching, contextinformatie en risicosignalen in als het identity platform die ondersteunt. Zonder die maatregelen kan een aanvaller gebruikers overspoelen met meldingen totdat iemand per ongeluk goedkeurt.

FIDO2 en WebAuthn zijn de juiste standaard voor administratieve accounts, productieomgevingen en developer-accounts met hoge waarde. De private sleutel verlaat het apparaat niet. Daardoor krijgt een aanvaller bij een nagemaakte website geen bruikbaar geheim dat eenvoudig opnieuw kan worden afgespeeld.

Biometrie is meestal geen zelfstandige factor voor enterprise-governance, maar ontgrendelt een apparaat of passkey. Beoordeel daarom altijd de volledige keten, inclusief toestelbeheer, recovery en accountbinding.

Kies SMS alleen als noodoplossing, TOTP als ondergrens, en push of FIDO2 als standaard voor beheerders en API-beheerders.

Ontwerp en gebruikerservaring van MFA

Een goede MFA-ervaring begint met risicogebaseerde accountclassificatie. Het NCSC adviseert om accounts in te delen naar impact, zodat de sterkte van de factor past bij de gevolgen van misbruik. Een medewerker die alleen objectinformatie raadpleegt, heeft een ander authenticatiepad nodig dan een beheerder die datasets, productiecredentials of gebruikersrechten kan wijzigen.

Deel accounts op vóór je een factor kiest

Gebruik minimaal deze drie groepen:

• Beheeraccounts: kies de sterkste beschikbare factor, bij voorkeur phishing-resistente hardware keys of passkeys. Vereis herauthenticatie bij gevoelige beheeracties.
• Medewerkeraccounts: gebruik standaard MFA en voeg step-up-authenticatie toe bij afwijkend gedrag, nieuwe apparaten of handelingen met hoge transactiewaarde.
• Serviceaccounts: laat machines niet werken met menselijke MFA. Gebruik certificaten, workload identity of kortlevende tokens met beperkte rechten.

Adaptieve authenticatie gebruikt context zoals apparaatstatus, locatie, sign-in-geschiedenis en de gevoeligheid van de handeling. Een gebruiker kan een woningkenmerk raadplegen zonder extra prompt, maar moet opnieuw authenticeren voordat diezelfde gebruiker exports maakt, API-rechten wijzigt of een koppeling met een extern systeem activeert.

Ontwerp herstel alsof het misgaat

Recovery is geen bijzaak. Beschrijf vooraf wat er gebeurt bij een verloren telefoon, een defecte hardware key, een vertrek van een medewerker of een geblokkeerd account. Backupcodes moeten beschermd worden opgeslagen, geregistreerde factoren moeten beheersbaar blijven en de helpdesk moet identiteit controleren zonder een zwakke achterdeur te creëren.

Serviceaccounts vormen een apart risico. Een CI/CD-pipeline kan niet op een pushmelding wachten. Koppel zo'n pipeline aan federated identity, workload identity of certificaten, beperk de scope en registreer iedere uitgifte en intrekking. Gedeelde menselijke accounts zijn geen acceptabele oplossing voor automatisering.

Meet vervolgens of de beveiliging werkt in de praktijk:

• Adoptiegraad: hoeveel relevante accounts hebben een actieve factor?
• Loginbelasting: hoeveel helpdesktickets ontstaan rond MFA?
• Tijd-tot-succes: hoe snel voltooit een gebruiker een legitieme login?
• Recoverykwaliteit: hoeveel uitzonderingen worden buiten het formele proces afgehandeld?

Documenteer deze metingen per accountklasse. De developer experience-aanpak van Altum AI biedt een passend referentiekader om beveiliging, documentatie en integratiegedrag samen te beoordelen.

MFA implementeren voor API-toegang en developer-accounts

MFA beschermt menselijke toegang tot API-beheer, maar niet de machine-aanroep zelf. Een developer moet MFA gebruiken voor de identity provider, cloudconsole, code repository en beheerportaal. Een service die woningdata opvraagt, gebruikt daarentegen een machinecredential, zoals een certificaat, workload identity of zorgvuldig beheerde API key.

Scheid menselijke en machinale identiteiten

Gebruik voor menselijke gebruikers OAuth 2.0 en OpenID Connect waar mogelijk. Laat de identity provider MFA afdwingen en geef daarna een short-lived access token uit. Gebruik refresh tokens alleen waar nodig, roteer ze bij gebruik en trek ze in bij een verdachte sessie of wijziging in de gebruikersstatus.

Beperk permissions per dataset, functie en omgeving. Een applicatie die energiekenmerken nodig heeft, hoeft niet automatisch transactiedata of verzekeringsgerichte endpoints te kunnen opvragen. Maak scopes leesbaar, toetsbaar en gekoppeld aan een eigenaar.

Behandel API keys als secrets

Een API key is geen vervanging voor menselijke MFA. Sla keys op in een secret manager, nooit in broncode, tickets of configuratiebestanden die breed toegankelijk zijn. Gebruik afzonderlijke credentials voor development, test en productie. Geef iedere integratie een eigen identiteit, zodat je misbruik kunt intrekken zonder andere processen te breken.

Log minimaal uitgifte, gebruik, scopes, actor, applicatie en intrekking. Automatiseer rotatie waar dat kan. Voor langdurige machineverbindingen verdienen certificaten of federated identity vaak de voorkeur boven statische sleutels.

CI/CD-pipelines moeten geen gedeeld productiewachtwoord gebruiken. Laat de pipeline via federated identity tijdelijk rechten verkrijgen en beperk die rechten tot de deploymentactie. Bescherm de broncodeomgeving en de identity provider met menselijke MFA, want daar kan een aanvaller anders nieuwe secrets of releases creëren.

Monitor tokens en clientgedrag

Let op tokenhergebruik, afwijkende clients, ongebruikelijke scopecombinaties en plotselinge aanvraagpatronen. Revoke tokens bij personeelswijzigingen, incidenten en een gewijzigde integratie. DPoP of andere sender-constrained patronen kunnen helpen om tokens aan een sleutel of client te binden, zodat een buitgemaakt bearer-token minder bruikbaar is.

Voor concrete keuzes rond tokens, keys en logging kun je de API-beveiligingsprincipes van Altum AI naast jullie eigen IAM-standaard leggen. Het doel is niet alleen een login beveiligen, maar de hele keten van developer tot dataset aantoonbaar begrenzen.

Compliance en best practices voor MFA

MFA is geen losse feature, maar een controlemiddel binnen toegangsbeheer, gegevensbescherming en operationele weerbaarheid. ISO 27001 vraagt om passende beheersmaatregelen voor authenticatie en toegang. De AVG verlangt volgens artikel 32 passende technische en organisatorische maatregelen. MFA kan daar een aantoonbare bouwsteen voor zijn, zolang je de keuze koppelt aan risico, scope en bewijs.

Maak de controle toetsbaar

Leg per systeem vast:

• Risico: welke woningdata, persoonsgegevens of bedrijfsprocessen zijn bereikbaar?
• Accountklasse: gaat het om een medewerker, beheerder, leverancier of workload?
• Factor: waarom past TOTP, push, passkey of FIDO2 bij dit risico?
• Uitzondering: welke accounts kunnen niet direct MFA gebruiken, en waarom?
• Review: wie controleert de keuze, met welke frequentie en op basis van welk bewijs?

NIS2 legt nadruk op MFA voor toegang met verhoogde rechten en kritieke systemen. DORA stelt voor financiële instellingen en relevante ICT-leveranciers hoge eisen aan ICT-risicobeheer en toegangscontrole. Voor banken en hypotheekverstrekkers betekent dit dat MFA niet los mag staan van leveranciersbeheer, incidentrespons, logging en continuïteit.

Phishing-resistente factoren verdienen de voorkeur voor beheerders, developers en externe leveranciers met brede toegang. Centrale IAM voorkomt versnipperde uitzonderingen. Logging moet laten zien wanneer een factor is geregistreerd, vervangen, gebruikt, geweigerd of omzeild. Periodieke toegangsreviews moeten niet alleen gebruikersaccounts bekijken, maar ook serviceaccounts, OAuth-clients, API keys en oude integraties.

Beheer noodscenario's gecontroleerd

Een noodaccount kan nodig zijn, maar mag geen permanente achterdeur worden. Gebruik sterke credentials, bewaar ze onder gescheiden beheer, registreer ieder gebruik en laat de organisatie na een incident direct beoordelen of de account nog nodig is. Een helpdeskflow voor factorherstel moet identiteit controleren met onafhankelijke signalen, niet met informatie die al uit een gecompromitteerde mailbox kan komen.

Een auditor wil niet alleen zien dát MFA aanstaat. Die wil kunnen volgen waarom de factor is gekozen, welke uitzonderingen bestaan en hoe jullie controleren dat de maatregel werkt.

Koppel de audittrail aan beleid, risicoanalyses, IAM-configuratie, trainingsmateriaal, incidenten en reviewbesluiten. Zo wordt MFA onderdeel van governance in plaats van een vinkje in een identity platform.

Voor woningdata geldt bovendien dat authenticatie niet het hele AVG-vraagstuk oplost. Beperk data tot wat de use case nodig heeft, leg verwerkingsdoelen vast, beheer bewaartermijnen en controleer leveranciers. Een woningwaardemodel, energielabel-API of transactiekoppeling vraagt dezelfde discipline: herleidbaarheid, toegangsbeperking en aantoonbare wijzigingen.

Veelgestelde vragen over multi-factor authentication

Is MFA voldoende om API-toegang te beveiligen?

Nee. MFA beschermt menselijke toegang tot beheer- en developer-accounts. API's hebben daarnaast scoped tokens, secret management, rotatie, logging, autorisatie en monitoring nodig.

Welke MFA-factor kies je voor een developer-account?

Kies bij voorkeur FIDO2 of WebAuthn, bijvoorbeeld via een hardware key of passkey. TOTP is een bruikbare ondergrens voor oudere systemen, maar is niet phishing-resistent. SMS hoort alleen bij een tijdelijke noodoplossing.

Hoe bescherm je serviceaccounts?

Gebruik geen menselijke MFA-flow voor een serviceaccount. Kies federated identity, workload identity, certificaten of een per omgeving gescheiden API key. Beperk rechten, roteer credentials en log gebruik.

Hoe toon je MFA aan tijdens een audit?

Bewaar beleid, accountinventaris, factorregistraties, uitzonderingsbesluiten, logs en reviewresultaten. Laat zien welke risicoafweging achter iedere factor zit en wanneer de organisatie die keuze opnieuw beoordeelt.

Altum AI ontsluit woningdata via API's voor onder meer woningkenmerken, waarde, energie en verduurzaming, waarbij menselijke toegang en machine-to-machine-toegang apart moeten worden ingericht. Bezoek Altum AI om de beschikbare API's, documentatie en integratiemogelijkheden voor jullie woningmarktapplicatie te bekijken.

Laatst bijgewerkt: 18 september 2026

Auteur: security-architect bij Altum AI, met focus op IAM, API-governance, woningdata en auditbare integraties voor Nederlandse financiële en vastgoedorganisaties.