Why authentik for education starts with three user lifecycles
authentik fits education when the institution wants to run its own single sign-on for campus systems and keep identity data inside infrastructure it controls. The change it brings is in the identity model: students, staff and alumni arrive, change and leave on different schedules, so one flat user pool with one set of rules will not hold up. A student account is tied to enrollment terms, a staff account to employment and contract dates, and an alumni account to a relationship that may continue for decades with a much smaller set of applications. Before any build, the registrar, HR and IT teams should agree on which source creates each account type, which groups or attributes mark its state, and who can change those attributes.
authentik is self-hosted, so the server, worker and PostgreSQL database run in the university's own cloud account, data center or private network. That matters for education records, which fall under the access and disclosure rules in FERPA, and for the account data that connects them. The identity design should therefore be written down with the data flows, the locations of the database and backups, and the people who administer them. Confirm with your counsel and privacy office how these obligations apply to your institution, since the rules depend on which federal funds the institution receives and on the populations it serves.
On editions, the authentik pricing page lists an Open Source edition at no cost with community support, and an Enterprise edition priced per user with a separate charge for external users. The pricing page lists Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication and enhanced audit logging as Enterprise-only. Before you plan around any of these, check whether your alumni or guest access, audit requirements or directory integrations depend on them, and ask the vendor to confirm current terms for your user counts.
Which education requirements shape the authentik build
This table maps each education-related requirement to what it asks of the institution and what it means for groups, provider scoping and audit records in an authentik deployment. Read each row as a design input to raise with your compliance lead and counsel, not as a legal conclusion. The main takeaway is that FERPA access control, access logging and the GLBA multi-factor rule shape the identity design more than any single product feature.
| Requirement | What it asks for | What it means for the authentik build |
|---|---|---|
| FERPA school official and access control (34 CFR 99.31) | Outside contractors may act as school officials only under direct institutional control, and the institution must limit access to records to staff with legitimate educational interests. | Model staff, faculty and vendor access as separate groups. Scope each application provider and its bindings so that users see only the systems their role requires. Confirm the contract terms with counsel before giving any vendor or integrator an account. |
| FERPA access logging (34 CFR 99.32) | Record each request for and disclosure of personally identifiable information from education records, with the parties and their legitimate interests, for as long as the records are kept. | authentik's audit trail records authentication and administrative events, but a FERPA disclosure log is a separate institutional record. Confirm what your institution must log, where it is stored and how long it is retained, then forward authentik events to that store. |
| FERPA inspection timelines (34 CFR 99.10) | Comply with a parent's or eligible student's request to inspect records within a reasonable period and not more than 45 days after receipt. | Identity data that supports inspection requests, such as account attributes and group membership history, must be findable quickly. Plan attribute naming, user lookup procedures and export steps so the records team can respond within the deadline. |
| GLBA Safeguards multi-factor rule (16 CFR 314.4) | Institutions in the Title IV programs must have a written information security program and multi-factor authentication for anyone accessing any information system. | Enforce MFA through authentik flows for all staff and student accounts that reach systems holding financial aid data. Identify which providers fall in scope and document any exceptions, such as service accounts, with compensating controls. Confirm your Program Participation Agreement obligations with your financial aid office. |
| COPPA for users under 13 (16 CFR 312) | Operators collecting personal information from children under 13 need a written security program, annual risk assessments and a retention policy with a deletion timeframe. | Relevant mainly to K-12 deployments or course tools used by younger children. Avoid collecting unnecessary profile fields, set account expiry and deletion steps, and confirm with counsel whether any vendor or app in the flow is an operator. |
| GDPR and NIS2 (EU institutions) | GDPR governs lawful processing and data minimization for personal data of people in the EU. NIS2 sets cybersecurity risk management duties for covered entities, including some education and research organizations depending on size and national transposition. | Document the lawful basis for each identity attribute, limit retention of leavers' accounts, and plan data location for the deployment. Confirm with your data protection officer whether NIS2 applies and how your national law implements it. |
How students, staff and alumni need different identity lifecycles
Student identities usually originate in the student information system, which records admission, enrollment, registration status and withdrawal. That system should be the source of truth, and authentik should receive accounts from it through a directory sync, an inbound SCIM feed or a scripted import rather than from manual entry. Enrollment creates the account and the group memberships that map to courses, programs and cohorts. Withdrawal or a change in enrollment status should remove or disable access, and the exact trigger points need to be agreed with the registrar.
- Source of truth: the student information system, with the registrar owning status codes that authentik reads.
- Enrollment trigger: a new admission or registration record creates the user and adds cohort and program groups.
- Applications reached: the LMS (for example, Moodle), the library, campus portal, email and course tools.
- authentik objects: group-based application bindings, enrollment flows for first login and policies that deny access when a status flag is off.
- Deprovisioning trigger: withdrawal, non-enrollment or a status change, with the removal timing confirmed against your registrar's process.
Check whether your student records fall under FERPA access rules and how your registrar logs disclosures to third-party tools.
Staff identities are usually tied to HR records and to appointment dates, contract terms and department assignments. Faculty and staff often hold broader access than students, including administrative systems, grading tools and finance applications, so their groups need tighter review. HR should remain the source of truth, and authentik should reflect changes in role and department without leaving old group memberships in place when someone moves.
- Source of truth: the HR system, feeding authentik through a sync, SCIM or a managed import.
- Joiner trigger: an approved appointment creates the account and assigns role-based groups.
- Mover trigger: a department or role change removes old groups before adding new ones, so access does not accumulate.
- Applications reached: email, the LMS as instructor, student information administration, finance and research systems.
- authentik objects: role groups, application access bindings, MFA stages enforced for administrative groups.
Ask HR which events produce a change record, and whether that record arrives in time to remove access on the last working day.
Alumni are the population most often left out of lifecycle design. Once a student graduates, the institution may still want to offer email forwarding, career services, library access or an alumni portal, but the account should no longer carry student-only entitlements. The key decision is whether alumni receive a separate identity type, a continued affiliation with a reduced group set, or no campus login at all. That decision should be recorded before the first graduating class is processed.
- Source of truth: the registrar's graduation or program-completion record, which should change the affiliation rather than delete the person.
- Transition trigger: graduation moves the user out of student groups and into a limited alumni group, if the institution offers one.
- Applications reached: typically a small set, such as alumni portal, library resources or career tools; the LMS student course access should end.
- authentik objects: a dedicated alumni group, binding rules that remove student application access, and enrollment or invitation flows for re-entry.
- Retention question: how long a retained alumni account stays active, and what happens if it is not used.
Confirm the alumni retention policy with the registrar and the data protection officer before configuring any transition rule.
External contractors, vendors and visiting researchers need access to specific systems for a defined purpose. Their identities should not be created by copying staff records, and each account should carry a sponsor, a reason for access and an expiry condition. In authentik, an expiry date can be set on the user account, and access should be granted through a dedicated group that is reviewed on a schedule your security team sets.
- Source of truth: a sponsoring department's request, recorded in a ticket or form, rather than an HR feed.
- Enrollment trigger: an approved sponsor request, using an invitation flow with a defined expiry.
- Applications reached: only the systems named in the sponsor request, such as a specific course space or research tool.
- authentik objects: an external user group, invitation flows with controlled enrollment, and per-application bindings.
- Deprovisioning trigger: contract end, sponsor withdrawal or the expiry set at creation.
If contractors receive education records in any form, confirm whether they qualify as school officials under FERPA's outside-party conditions before granting access.
Schools serving children under 13 face separate obligations. Where a school or an operator collects personal information from children, the COPPA Rule requires a written information security program, a designated coordinator, periodic risk assessments and a written retention policy with a deletion timeframe. Identity accounts for younger pupils should therefore carry as little personal data as the learning need allows, and parent or guardian involvement should be designed into the enrollment process rather than added later.
- Source of truth: the school's pupil records, with guardian contact data held separately from login data.
- Enrollment trigger: an approved admission, with parental consent handled through the school's own process.
- Applications reached: a restricted set of learning tools, typically with no open messaging or public sharing.
- authentik objects: a dedicated pupil group, policies that restrict self-registration, and password and recovery flows tuned for younger users.
- Retention and deletion: a written schedule for removing accounts and data after the pupil leaves.
Check with counsel which of the COPPA Rule duties apply to your school and to each vendor that processes pupil data.
Which authentik providers and settings matter on campus
Campus identity usually combines modern SSO for the LMS and portals, legacy LDAP clients, Wi-Fi authentication and group rules that follow educational need. Each provider and setting below carries a different risk, so confirm the capability in the authentik documentation before the build starts.
OAuth2/OIDC and SAML for LMS and campus apps
Most learning platforms and campus portals can sign users in through OAuth2/OIDC or SAML, and authentik provides both provider types. For Moodle, the core OAuth 2 and Shibboleth authentication plugins and the SAML2 plugin are the paths to check, since each depends on how the site is configured. Confirm which protocol each application supports, the redirect URIs it requires, and how it maps attributes such as student number and role before you create the providers.
LDAP for legacy clients
Older applications, printers, lab systems and some Moodle deployments can only bind to a directory. authentik's LDAP provider exposes users and groups to those clients so they do not need local accounts. Test bind behavior, the search base, and which attributes each client reads. Treat the LDAP path as a compatibility layer and confirm how multi-factor authentication applies to it, since many legacy clients cannot prompt for a second factor.
RADIUS provider for Wi-Fi
Campus Wi-Fi commonly authenticates students and staff over WPA2 or WPA3 Enterprise through RADIUS. authentik documents a RADIUS provider, so the access points and controllers must be able to send requests to it and accept its responses. Confirm the EAP methods your wireless controllers support, the shared secret handling, the network path from the access points, and how device certificates or passwords are issued to users who rotate roles.
SCIM for provisioning where supported
SCIM lets a campus system create, update and disable accounts in downstream applications when a person's status changes. Use it only for applications that document SCIM support, and confirm which operations (create, update, deactivate, group sync) each one implements. Provisioning and deprovisioning timing decides whether a graduated student or departed staff member keeps access, so map the source of truth for each population before you turn it on.
Group-based access tied to educational need
Access to course, grade and records systems should follow groups that reflect a documented legitimate educational interest, such as enrolled courses, department or role. Under FERPA, institutions must use reasonable access controls so school officials see only the records they need. Design groups and policy bindings with the registrar and data owners, keep group membership reviewable, and record who approved each access path.
Enhanced audit logging on Enterprise
Enhanced audit logging is listed as an Enterprise-only feature on the authentik pricing page, so it is not part of the Open Source edition. If your access reviews, incident response or records requests depend on detailed sign-in and administrative event history, ask for the current edition comparison in writing and confirm the retention and export options. Without it, plan to forward standard logs to your own store and test that they answer the questions you will be asked.
Connecting Moodle and other LMS platforms to authentik
Moodle decides how a user signs in through its authentication plugins, and that choice determines what authentik must provide. Moodle core ships OAuth 2, LDAP and Shibboleth authentication plugins, so an OAuth 2 or OIDC connection to authentik needs no marketplace add-on, while SAML is available through the community-maintained SAML2 Single sign on plugin listed on the Moodle marketplace. Before building, confirm which method your Moodle version supports, check the plugin's compatibility with that exact release, and record who maintains the plugin and how it is patched. An LDAP connection through authentik's LDAP provider is possible, but it means the LMS handles passwords through a directory bind, which changes how multi-factor authentication applies. Agree the method with the academic systems owner before any configuration starts.
Upgrade timing will shape the plan as much as the authentication choice. Moodle 5.1 requires the web server document root to point to the new public directory instead of the main Moodle folder, so reverse proxy and web server configuration must change during that upgrade, and sites on Moodle 4.2.3 or later can upgrade to it. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, and sites running Moodle 4.4 or later, which may also mean a PHP and database upgrade on the same host. Moodle ships major releases in April and October and point releases every two months, so schedule the authentik integration and any Moodle upgrade in the same change window. Ask your vendor or internal team to confirm the current support windows on the Moodle releases page before choosing a target version.
How a campus authentik rollout is phased
The sequence moves identity in controlled stages so each population and application is proven before the next one depends on it, and legacy Shibboleth, CAS and RADIUS paths are retired only after evidence shows they are no longer needed. Each stage closes with a sign-off the institution owns.
Inventory applications and identity sources
Before any configuration, the institution lists every application that relies on Shibboleth, CAS, LDAP, RADIUS or local accounts, including the LMS, library systems, email, the student information system, Wi-Fi controllers and VPN. For each one it records the protocol, the attributes the application expects, the population that uses it and the data owner. DeployOpen can run this inventory with your identity and application owners. It is done when every application has an owner, a protocol and a target authentik provider type, and the registrar and data owners have signed off on which student and staff attributes will be released. This is the point where FERPA school official and legitimate educational interest decisions are written down.
Bridge federation while Shibboleth or CAS remains
Where legacy Shibboleth or CAS services must keep running, authentik is connected as an identity source or federation partner so that users can sign in through authentik while existing relying parties continue to work. Attribute mapping is tested against each legacy service, and the team confirms which claims or attributes each service actually consumes. The bridge is complete when a test account can reach every legacy service through the new path and the old login path produces the same attributes. The institution signs off on the attribute release list, since this is the period in which two sign-in paths coexist and must be audited together.
Pilot with one LMS and one population
A single population, typically a small group of staff or instructional designers, signs into one LMS through authentik, using OIDC, SAML or LDAP according to what the LMS supports. Moodle core includes LDAP, LTI, OAuth 2 and Shibboleth authentication plugins, so the team confirms which of these matches the chosen design and whether a plugin such as SAML2 SSO is needed. The pilot proves login, logout, role mapping from group membership, and account creation for new users. It is done when the pilot group completes a full course cycle task list without manual intervention and the LMS administrator confirms the mapping. Results and open issues go to the sponsor for a go or no-go decision.
Move staff accounts to authentik
Staff are moved next because their accounts are usually the most controlled and their access is most visible to administrators. The team configures authentik flows for staff enrollment, multi-factor authentication and password recovery, and migrates or links directory accounts as the design requires. Each campus application in the inventory is switched to authentik in agreed batches, with a rollback path kept for each batch. The stage closes when every staff-facing application signs in through authentik, the MFA policy is enforced, and the identity owner has reviewed the access logs for failed and unexpected sign-ins.
Move student accounts to authentik
Students are moved after staff, in cohorts or by application, so that high-volume sign-in peaks are observed on a smaller base first. Enrollment and lifecycle rules are tested with the registrar's data feed, including how new students are created and how withdrawn students lose access. Capacity of the server and worker containers and the PostgreSQL connection count are checked under real load, since authentik keeps its caching, tasks and sessions in PostgreSQL. The stage is complete when student sign-ins succeed across the agreed applications, support tickets are within the agreed range set by the service owner, and the registrar confirms that lifecycle changes reach authentik correctly.
Migrate alumni access last
Alumni are moved last because their accounts depend on lifecycle rules that differ from enrolled users, and because some alumni services may be external or only occasionally used. The institution confirms which alumni services remain in scope, what an alumni identity looks like in authentik, and how alumni access ends or continues. Any external users are given a designed enrollment and recovery path. The stage closes when alumni access is tested against the documented policy and the data owner has approved the retention and deletion approach for alumni records.
Cut over RADIUS Wi-Fi authentication
Wi-Fi is cut over after the directory and sign-in path are stable, since RADIUS clients depend on the same accounts and credentials. The network team configures authentik's RADIUS provider for the access points or controllers, tests each SSID with staff and student test accounts, and confirms how MFA is handled for protocols that allow it. A rollback to the previous RADIUS source is kept until the cutover is accepted. The stage is done when each SSID authenticates users from authentik in the agreed test matrix and the network owner signs off on the cutover window and rollback plan.
Retire legacy services with evidence
Legacy Shibboleth, CAS, RADIUS and directory paths are switched off one at a time, only after the access logs show no remaining use and the application owner confirms the replacement. The team removes or archives the old configuration, revokes stale service accounts and records the decommissioning in the access inventory. Evidence of each retirement is kept with the FERPA access and disclosure records the institution maintains. The sequence closes when the inventory shows no active legacy path, each retirement has an owner sign-off, and the retained records are stored where the institution's retention rules require.
What compliance evidence an education deployment must produce
An education deployment of authentik touches student records, so the access controls around it need to be provable. The cards below list the evidence an institution typically assembles from FERPA, the GLBA Safeguards Rule and, where children under 13 are involved, COPPA. DeployOpen prepares systems, controls and evidence for your review, but independent auditors and certification bodies make the determinations.
Access control records
Keep a record of who can reach which applications, and why. In authentik, this means exporting application bindings, group membership and policy assignments so that each school official's access maps to a legitimate educational interest. FERPA expects reasonable access controls that limit school officials to the education records they need, so review whether a staff group in authentik grants access to a student information system, a gradebook or a finance tool. Confirm that every binding has an owner and a review date.
MFA coverage reports
Evidence of multi-factor authentication shows which accounts use a second factor and which applications enforce it. For institutions also subject to the GLBA Safeguards Rule, MFA is required for anyone accessing an information system that holds student financial data. Build a report from authentik's login events and flow configuration that counts accounts without an enrolled factor, and track exceptions such as LDAP or RADIUS clients that cannot prompt for a second factor. Confirm how each exception is documented and approved.
Written information security program
The Safeguards Rule requires a written information security program, and COPPA requires a written program with a designated coordinator for operators collecting data from children under 13. For authentik, the document should name the people who administer the identity provider, the hosting boundary, the change process for the server and worker containers, and the escalation path for suspected account compromise. Attach the authentik deployment diagram and the list of connected applications so the program describes the system as it runs.
Retention and deletion rules
Retention rules for identity data decide how long authentik keeps user records, events and deactivated accounts. COPPA requires operators to keep children's personal information only as long as reasonably necessary and to document a deletion timeframe. Define the retention period for inactive student and alumni accounts in your written policy, then confirm that your authentik configuration and PostgreSQL backups follow it, including the backup copies that hold old records. Ask your team how deletion requests are carried out across backups.
Disclosure and access logs
FERPA requires a record of each request for access to, and each disclosure of, personally identifiable information from an education record, including the parties and their legitimate interests. In authentik, the audit trail of sign-ins and application launches can support this, but it does not record the purpose of a disclosure by itself. Forward authentication logs to your log platform, set retention to match the period the records are kept, and document how staff match a log entry to a disclosure request. Confirm which events your edition logs and retains.
Contractor access documentation
When DeployOpen or another contractor administers the deployment, FERPA allows a contractor to receive education records only as a school official under the institution's direct control. Keep a record of each administrator account, the scope granted to it, and the agreement that places the contractor under your control. Review this list at each handover and remove accounts when the engagement ends. Ask for the same list in any vendor or partner quote so that access can be audited later.
What education teams ask before hiring a partner
What drives the cost of an authentik deployment for a school or university?
The largest cost drivers are the number of identity sources and applications to connect, the number of user populations with different lifecycles, the amount of federation to run during migration, and whether you need Enterprise features. authentik's Open Source edition is free to use under the MIT license for most of the code, but the pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Those are subscription fees paid to authentik, not to DeployOpen. Ask any partner for a quote that separates one-time implementation work from recurring subscription and support costs, and confirm which features in your scope require a paid edition.
How long does an authentik rollout take for a university with several Shibboleth applications?
Duration depends on how many applications must move, how many have custom attribute mappings, and whether Shibboleth or CAS stays live in parallel during cutover. No single timeline applies across institutions, so treat any figure you hear with caution. The useful questions are how many protocols and applications are in the first wave, which directories or student information feeds must be synchronized, and how many test cycles with pilot departments are planned. A partner should give you a fixed-scope timeline in writing after reviewing those inputs.
What must the institution provide before an implementation partner can start?
The partner will need access to the environment where authentik will run, the list of applications and their protocols, the identity sources such as a student information system, HR feed or existing directory, and named owners for each application. You should also provide the attribute and group rules that decide who can sign in to which application, plus test accounts for students, staff and alumni. Confirm early who approves changes to the Shibboleth or CAS configuration and who handles privacy review of the attributes released to each service.
Can our IT staff deploy authentik themselves using Docker Compose or Kubernetes?
Yes, a small team can build a test environment from the official guides, and the Docker Compose guide positions Compose for test setups and small-scale production on a host with at least 2 CPU cores and 2 GB of RAM. The Kubernetes guide installs with Helm. Self-deployment is practical when you have someone comfortable with containers, reverse proxies, backups and upgrades, and time to run pilots. The harder part is usually the integration work with each school or university application, so estimate that effort separately from the installation.
Should production authentik use the PostgreSQL bundled with the Helm chart or a separate database?
Use a separately managed PostgreSQL for production. The authentik Kubernetes guide says the PostgreSQL bundled with the chart is intended for demonstration and test environments and recommends a separately managed database for production. Your choice should cover backup and point-in-time recovery, high availability, connection capacity and who on campus owns the database after handover. Ask your partner how the database will be backed up, how restores will be tested, and who receives alerts when the database is unhealthy.
Does authentik still need Redis, and how many PostgreSQL connections should we plan for?
No. The authentik 2025.10 release notes state that authentik no longer uses Redis at all and moves caching, tasks, sessions and WebSocket functions to PostgreSQL. The same release notes warn of roughly 50% more PostgreSQL connections after upgrading, so review your connection limits and any pooling layer before the upgrade. If you are upgrading from an older version that used Redis, plan the removal of that dependency as part of the change, and confirm the connection budget with your database administrator during the pilot.
How is a Shibboleth or CAS cutover sequenced without locking students out?
A safe cutover normally runs both systems in parallel, moves one application group at a time, and keeps the legacy login path available until pilot users confirm access. Start by mapping every service that relies on Shibboleth or CAS, including the attributes and group values each one expects. Next, configure authentik to release the same attributes, test with a pilot group, and then move remaining applications in waves. Plan a rollback path for each wave and agree on a freeze period before term start. Confirm with each application owner whether their software supports SAML or OIDC in the form you need.
How DeployOpen scopes an education authentik implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the institution's own infrastructure. For authentik for education, we start with a written scope that separates student, staff and alumni populations, the federation path from Shibboleth or CAS, and the applications that must sign in through authentik.
How we scope
- Inventory every application, LMS, campus service and Wi-Fi controller that will authenticate through authentik
- Map student, staff and alumni lifecycles to the groups, sources and enrollment flows each one needs
- Agree the Shibboleth or CAS migration sequence and the coexistence period in writing before build starts
- Confirm hosting, PostgreSQL and reverse proxy choices against the institution's infrastructure and edition needs
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
How we build
- Deploy authentik in the institution's own cloud account, data center or network using the documented installation method chosen in scope
- Configure OAuth2/OIDC and SAML providers for the LMS and campus apps, and RADIUS for Wi-Fi where the scope requires it
- Set up federation and attribute mapping so each user population receives only the access its role needs
- Test sign-in, MFA, role changes and offboarding paths for each application and each user group before cutover
- Document configuration, runbooks and the access rules that map to the institution's educational-interest controls
How we hand over
- Deliver configuration documentation, architecture notes and the list of providers, sources and flows in place
- Walk administrators through group management, lifecycle changes, upgrades and the sequential version upgrade rule
- Provide access records and change logs that support the institution's own FERPA and GLBA review
- Agree the operational procedures for backups, monitoring and lockout recovery before the handover closes
- Record open items and the vendor or policy questions that the institution still needs to confirm
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial build
- Track authentik security releases and plan upgrades around the supported versions listed in the security policy
- Retest applications and Wi-Fi authentication after LMS or identity platform upgrades that change behavior
- Keep the access model current as the institution adds programs, campuses or external alumni populations
- Scope any new work, such as additional federation or applications, in a separate written agreement
