Situation
A college in Kaunas, Lithuania, has used Microsoft 365 for more than ten years: e-mail, Teams, OneDrive and SharePoint for lecturers, administration and students. There are about 400 staff users and several thousand student accounts, and more are added every year. Administration was in the hands of a single IT employee, alongside all other duties: computers, classroom equipment, the network.
Over the years the college accumulated what accumulates everywhere accounts are created by hand and disabled “when someone remembers”. Former students had working accounts with e-mail and access to Teams channels containing study materials. So did lecturers who had left, some with shared SharePoint libraries. Multifactor authentication was enabled only for those who wanted it themselves, which was a minority. Licences had been bought for the highest number ever reached and had not been reviewed since.
They contacted us after two events: remarks from a cybersecurity review about MFA, and a phishing case in which e-mails to lecturers were sent from a former student’s account. The college’s management wanted administration to run by process, not by memory, and the IT employee to be able to return to their other work.
What was needed
- An account lifecycle linked to the student and HR systems: enrolment creates, departure disables, with no manual work.
- Mandatory MFA for all accounts, with an exception list only for shared classroom and laboratory accounts.
- Conditional access: access to administrative systems only from managed devices and only from Lithuania.
- A licence review and a clear rule on which licence is assigned to which role.
- A transition without interruptions during the semester and without a flood of calls to IT.
What we did
Weeks 1-3: audit and the account journey
After taking over Microsoft 365 administration, we started with an audit of the tenant: how many accounts, when each last signed in, which licences, who holds administrator rights, what the sharing settings are. The picture was what we expected: about a third of the accounts had not signed in for over a year, some of them with paid licences, and there were eight global administrators, two of whom no longer worked there.
Together with the student office and HR we mapped the account journey from the enrolment order to removal from the register. We agreed which system is the source of truth for each role, when an account must be disabled and when it must be deleted.
Weeks 4-7: Entra ID lifecycle
We configured Microsoft Entra ID so that accounts are created and disabled from the data in the student and HR systems: a new record creates an account with the licence and groups assigned to the role, a changed status disables sign-in within a day, and after an agreed period the account is archived and the licence is freed. We disabled old accounts in waves, notifying the faculties a week before each wave so that anyone who still needed access had time to respond. Few did.
Weeks 8-10: MFA and conditional access
We enabled MFA in stages: first administration and lecturers, then students by faculty. For each stage we prepared short instructions in Lithuanian and English and a registration window in which users could set up the app at their own pace. The conditional access rules: student and HR systems only from managed devices, administrator accounts only with phishing-resistant MFA, and sign-ins from unusual countries blocked. The most difficult part was the shared classroom accounts, for which we created a separate rule restricting access to the college network.
Weeks 11-12: licences and handover
We redistributed licences by role: education plans for students and lecturers, administration according to actual need, and no paid licences for shared accounts. Three administrators remained, all with separate administrative accounts. We handed the IT employee a monthly report template and access to our helpdesk.
Result
All active accounts, 100%, have mandatory MFA; the exception list is short, documented and reviewed every quarter. No phishing e-mails from college accounts have been recorded since the change.
Paid licences fell by about 28%: part was freed by disabling unused accounts, part by changing plans to match roles. The savings stayed in the college’s budget for the following years.
Access is disabled within 24 hours of a change in the student or HR system, without the IT employee getting involved. We measure it from the Entra ID logs: the time from the status change to the account being disabled.
“Every September we used to have a week of creating accounts. This year they simply appeared, and it felt strange.”
What we would advise in a similar situation
- Start with the source of truth: until accounts are linked to the HR and student systems, every cleanup will be temporary.
- Disable old accounts in waves with advance notice rather than all at once, but do not postpone it just because “someone might be using it”.
- Introduce MFA in stages with instructions and a registration window; most of the resistance disappears when people can do it themselves.
- Review licences together with accounts, not separately: most of the time it is the same list.
