The majority of blockages on MyCampus Eduservices do not come from a forgotten password. Since the gradual activation of multi-factor authentication (MFA) on the Microsoft Education tenants of the group, the diagnosis has changed. We are observing that support tickets related to a misconfigured MFA or an unregistered device now represent a growing share of the login incidents reported by students and teaching staff.
Microsoft Entra ID MFA: the real bottleneck on MyCampus
Several schools in the Eduservices group have activated two-factor authentication via Microsoft Authenticator or SMS code, particularly for logins from outside the institution’s network. This measure follows the recommendations of ANSSI on strengthening authentication in higher education, updated in September 2024.
You may also like : How to Creatively Reveal Your Wedding Theme to Your Guests
The problem is that this additional layer of security is not always clearly communicated to new enrollees. A student who changes their phone or who has never installed Microsoft Authenticator finds themselves facing an authentication loop without an explicit error message.
We recommend checking three points before any further action:
You may also like : How to Properly Use a Compound Miter Saw?
- The Microsoft Authenticator app is installed and linked to the academic account (not the personal Microsoft account).
- The phone number registered for receiving the SMS code is still active and accessible.
- The default verification method in the security settings of the Microsoft account (aka.ms/mysecurityinfo) corresponds to the device used daily.
If the phone linked to the MFA is lost or broken, only the school’s IT service can reset the authentication method. No automatic recovery link allows bypassing this step.
To diagnose a problem with accessing MyCampus Eduservices, it is essential to first determine whether the blockage occurs before or after the password entry screen, which directly points to an MFA or identifier issue.
MyCampus login via browser versus Office 365 mobile apps
Access via browser and access via mobile app do not behave the same way. Since the gradual update of Microsoft Entra ID (formerly Azure AD) in early 2025, students report functional access via Chrome or Edge while Teams or Outlook on smartphones return a “non-existent account” message or an infinite login loop.
This discrepancy is explained by the management of authentication tokens. The browser renews the token with each session. Mobile apps, on the other hand, retain a cached token that may expire or conflict with a modified conditional access policy on the school’s Microsoft tenant.
Cleaning procedure on smartphone
The most reliable solution is to remove the academic account in the app settings (Teams, Outlook, or OneDrive), then manually re-add it. A simple restart of the app is not sufficient because the corrupted token persists in memory.
On Android, we also recommend clearing the cache of the Microsoft Authenticator app if the MFA validation is stuck in a loop. On iOS, deleting and then reinstalling the app is sometimes necessary when cache cleaning is not natively offered.
Browser cache and cookies: targeted purge for the Eduservices platform
Clearing the entire browser cache is common advice, but excessive. A targeted purge of cookies from the domain mycampus.eduservices.org and login.microsoftonline.com resolves the issue without logging out of all other accounts saved in the browser.
Quick method on Chrome and Edge
- Open the browser settings, section “Cookies and site data”.
- Search for “eduservices” and “microsoftonline” in the filter bar.
- Delete only the corresponding entries, then restart the browser before attempting to log in again.
- If the school uses an intermediate SSO portal, also delete cookies related to the domain of the concerned portal.
This approach avoids losing active sessions on other platforms. It is particularly useful when a student shares a workstation in a computer lab and inherits residual cookies from a previous user.
Institutional identifier and Microsoft tenant error on MyCampus
The login identifier is always the academic email address, in the format [email protected] (the exact domain varies by institution). Entering a personal Gmail or Outlook address results in an immediate rejection, often without a clear error message, because the school’s Microsoft tenant simply does not recognize the domain.
A common and poorly documented case: some students have two Microsoft accounts, one personal and one academic. The browser suggests auto-completion of the personal account, and the login fails silently. The Microsoft account selector (“Use another account”) allows forcing the entry of the correct identifier.
First login and temporary password
During the first login, the password is usually temporary and provided by the administration. This temporary password often expires after a few days if the first login is not completed within the allotted time. After this period, only the school’s technical support can regenerate a new temporary password.
After the first authentication, Microsoft requires a password change. The new password must meet the complexity requirements of the tenant (minimum length, special characters). A password rejected at this stage does not always generate an explicit message on mobile.
Eduservices technical support: which channel to use depending on the blockage
Not all support channels handle the same incidents. The school’s IT helpdesk manages password resets and MFA disassociations. The Eduservices group’s IT department handles tenant issues, account provisioning errors, or anomalies related to Microsoft Entra ID updates.
Before contacting support, we recommend noting the exact error message displayed (AADSTS code followed by numbers, if applicable). This code allows the technician to identify the cause in seconds, whereas a vague description (“it doesn’t work”) significantly prolongs the resolution time.
Login issues with MyCampus rarely stem from a global platform outage. In the vast majority of cases, the cause is local: desynchronized MFA, expired application token, incorrect identifier in auto-completion, or residual cookie. Identifying the exact layer of the blockage before seeking support saves time for everyone.