ChatGPT maakt accountcontrole concreter met beveiligingsgeschiedenis

ChatGPT heeft een beveiligingsgeschiedenis toegevoegd waarin gebruikers recente beveiligingsactiviteit van hun account kunnen terugzien. OpenAI maakte de functie op 25 september 2026 bekend. Voor scholen en onderwijsinstellingen is dit vooral nuttig als extra controlelaag: een docent, student of beheerder kan sneller nagaan of een onbekende aanmelding of wijziging aan de accountbeveiliging nader onderzoek vraagt.

De functie voorkomt geen incidenten en vervangt geen centraal identiteits- of logbeheer. Ze maakt individuele accountcontrole wel concreter, juist nu onderwijsgebruikers ChatGPT vaker koppelen aan documenten, apps en werkprocessen.

Wat er nieuw is

Volgens de officiële ChatGPT-release notes toont Security history recente aanmeldingen en afmeldingen, plus wijzigingen aan multifactorauthenticatie (MFA), passkeys en andere beveiligingsinstellingen. Per gebeurtenis kunnen tijd, locatie en apparaatgegevens zichtbaar zijn. OpenAI waarschuwt dat sommige details bij benadering zijn of kunnen ontbreken.

De beveiligingsgeschiedenis staat in ChatGPT op het web onder Settings → Security and login → Security history. De bron noemt geen aparte beperking tot een bepaald abonnement of onderwijslicentie, maar beschrijft de functie als accountinstelling voor ChatGPT-gebruikers.

De kansen

Voor docenten en studenten biedt het overzicht een begrijpelijke plek om verdachte activiteit te herkennen. Een onbekend apparaat, een aanmelding op een onverwachte locatie of een niet-herkende wijziging aan MFA kan aanleiding zijn om het account te beveiligen en de ICT-servicedesk in te schakelen. Daarmee wordt accountveiligheid minder abstract: teams kunnen een controle stap voor stap oefenen.

Voor onderwijsinstellingen kan de functie helpen bij voorlichting rond phishing, hergebruikte wachtwoorden en gestolen sessies. Laat gebruikers bijvoorbeeld bij een beveiligingsmelding niet alleen hun wachtwoord wijzigen, maar ook de recente geschiedenis controleren, actieve sessies beëindigen en nagaan of MFA of een passkey nog correct staat ingesteld.

Geen vervanging voor centraal beheer

Security history is een gebruikersoverzicht binnen één dienst. Het vervangt geen logs van de identityprovider, Microsoft 365 of Google Workspace, geen apparaatbeheer en geen incidentregistratie. Ook is een locatie-indicatie niet altijd precies: mobiele netwerken, VPN's en internetproviders kunnen een legitieme sessie op een onverwachte plaats tonen.

Trek daarom niet op basis van één afwijkend detail direct de conclusie dat een account is overgenomen. Vergelijk tijdstip, apparaat, gebruikte dienst en andere signalen. Bij een serieus vermoeden moeten beheerders ook gekoppelde apps, tokens, herstelmethoden en institutionele toegangslogs controleren volgens het eigen incidentproces.

Privacy, toetsing en afhankelijkheid

Een beveiligingslog bevat gegevens over tijd, apparaat en vermoedelijke locatie. Behandel screenshots of exports daarvan niet als gewoon lesmateriaal en deel ze alleen met medewerkers die ze voor ondersteuning of incidentonderzoek nodig hebben. Spreek ook af hoe zulke gegevens veilig bij de servicedesk terechtkomen en hoe lang een melding wordt bewaard.

Bij toetsen en vertrouwelijk onderwijswerk is accountbeveiliging extra belangrijk, maar een schoon overzicht bewijst niet dat werk zelfstandig is gemaakt. Gebruik Security history dus niet als fraudecontrole. Het overzicht zegt iets over accountactiviteit, niet over auteurschap, inhoudelijke betrouwbaarheid of wie fysiek achter het apparaat zat.

Scholen blijven bovendien afhankelijk van wat OpenAI registreert en zichtbaar maakt. Omdat details kunnen ontbreken of bij benadering zijn, hoort de functie thuis in een bredere beveiligingsaanpak met beheerde accounts, minimale rechten, MFA of passkeys, duidelijke appkoppelingen en een eigen meldroute.

Wat teams nu kunnen afspreken

• Laat medewerkers en studenten weten waar Security history staat en welke signalen zij moeten melden.
• Oefen de route bij een fictief incident: controleer activiteit, wijzig zo nodig het wachtwoord, herstel MFA of passkeys, beëindig verdachte sessies en waarschuw de ICT-servicedesk.
• Vergelijk een melding altijd met institutionele identiteits-, apparaat- en applicatielogs; behandel locatiegegevens als aanwijzing, niet als sluitend bewijs.
• Controleer na een vermoedelijke overname ook gekoppelde apps, gedeelde bestanden en eventuele toegang tot vertrouwelijke onderwijsinformatie.
• Leg vast dat beveiligingsgeschiedenis geen bewijs is voor toetsfraude of auteurschap en dat screenshots persoonsgegevens kunnen bevatten.

De kern

De nieuwe beveiligingsgeschiedenis maakt zichtbaar wanneer een ChatGPT-account is gebruikt en wanneer belangrijke beveiligingsinstellingen zijn veranderd. Dat geeft onderwijsgebruikers een bruikbaar extra signaal bij verdachte activiteit. De winst ontstaat pas als scholen het overzicht koppelen aan MFA of passkeys, centraal logbeheer, zorgvuldige omgang met persoonsgegevens en een geoefend incidentproces.