Open source identity governance for education

Open source identity governance for education: why campus lifecycles differ

midPoint can drive campus identity lifecycles from the student information system and HR, and the hard part is policy and data, not licensing. Registrars and CIOs at universities and colleges face a workforce that changes on a calendar: students enroll in bulk before semester start, staff and faculty arrive and leave on contract dates, alumni keep some access for years, and guests and research collaborators appear with sponsors and end dates. midPoint is an identity governance and administration (IGA) platform, written in Java and licensed under the European Union Public License (EUPL-1.2), with no enterprise edition, so the license does not decide the outcome. It provisions accounts and entitlements to target systems through connectors and records who approved what. It does not issue logins or single sign-on, so a separate SSO server such as Keycloak handles authentication, and the two must be designed together.

Platform choice matters less than the source-of-truth decisions made before any connector is built. For each population, the team must name the authoritative system, the attribute that identifies a person across the student information system, HR and directories, and the event that starts a joiner, mover or leaver change. A student record that is reactivated after a leave of absence, or a faculty member who also holds an emeritus appointment, can produce two conflicting sources. Ask the registrar and HR to write down which system wins for each attribute and what happens when they disagree. Confirm with the vendor and your own environment which connectors your directories and student systems need, since midPoint's connector catalog ranges from supported to experimental.

Deprovisioning is where campuses most often break research work. Removing an account when a graduate student's enrollment ends can also cut off a lab's shared storage, a data use agreement, or a sponsored project that still needs the person for another year. Decide, before go-live, which entitlements expire with the student role, which move to a sponsored or research role with its own end date, and who approves any exception. Alumni and guest accounts need the same rule set with different owners. Because FERPA requires institutions to limit school officials to records they have a legitimate educational interest in, role definitions should be reviewed with the registrar, not inherited from directory groups that have grown over years.

Which FERPA, GLBA and access rules shape the build

This table maps the federal rules that most often shape an education identity build to concrete decisions in midPoint, such as contractor access, role scoping and audit trails. Read each row as a requirement, then the build decision it forces and the evidence a reviewer will ask to see. The main takeaway is that FERPA school official conditions and access logging are design inputs for the connector and role model, not paperwork added after go-live.

Rule	What it requires	Build decision in midPoint	Evidence to keep
FERPA school official conditions (34 CFR 99.31(a)(1))	Outside contractors may receive education records only when they perform a service staff would otherwise perform, sit under the institution's direct control and follow redisclosure limits.	Tag contractor and vendor identities with a distinct type, scope their roles to the service contracted, and make sponsor and end date mandatory attributes.	Contract references, sponsor assignments and role definitions per contractor identity.
Legitimate educational interest (34 CFR 99.31(a)(1)(ii))	Institutions must use reasonable access controls so school officials see only the records in which they have a legitimate educational interest.	Model roles by function and organizational unit, such as registrar, advisor or department faculty, and exclude broad student-data entitlements from default bundles.	Role catalog with the business justification for each entitlement and the approver of record.
Access record keeping (34 CFR 99.32)	Institutions must record each access request and disclosure of personally identifiable information, with the parties and their interests, for as long as the records are kept.	Enable midPoint audit logging for provisioning and entitlement changes, and retain request and approval history alongside it. Confirm the retention period with your registrar and counsel.	Exported audit trail of who was granted or removed access to student record systems, with timestamps and approvers.
Inspection request window (34 CFR 99.10(b))	Requests from parents or eligible students to inspect records must be honored within a reasonable period and not more than 45 days after receipt.	Ensure the identity records that link a person to their student record can be located quickly, including historical and former-student accounts, so the registrar can answer within the window.	Documented lookup procedure and a tested query that returns a person's account history and systems they could reach.
Safeguards Rule MFA (16 CFR 314.4(c))	Multi-factor authentication is required for anyone accessing any information system at an institution covered by the GLBA Safeguards Rule.	Make MFA a condition of the SSO login for staff, contractors and administrators, and define exceptions as time-limited and approved in midPoint or the SSO server.	MFA enforcement settings per application and a list of approved exceptions with expiry dates.
Safeguards Rule activity logging (16 CFR 314.4(c))	Institutions must monitor and log the activity of authorized users on their systems.	Forward SSO and provisioning logs to the central log platform and map each privileged or data-bearing role to a log source that the security team reviews.	Log source inventory and sample records of authentication and entitlement events for a given user.
Enforcement exposure (34 CFR 99.67)	If an institution does not comply with FERPA, the Secretary may withhold payments, issue a cease and desist complaint or end funding eligibility.	Treat role scoping and audit trails as funding-relevant controls, and prioritize them in the first release rather than after the pilot.	Written control mapping that the compliance office signs off before each population is onboarded.
Program Participation Agreement scope (FSA GENERAL-23-09)	Institutions in Title IV programs agree to comply with the GLBA Safeguards Rule, which the Department of Education examines in annual audits.	Include student financial aid systems and their administrators in the first certification campaign and in the MFA scope, since they fall under GLBA.	Inventory of aid systems with named owners and last review date.

How the student and staff lifecycle is modeled in midPoint

This sequence turns the student information system and HR records into identities, entitlements and end dates in midPoint, so every account change traces back to an authoritative source and can be shown to an auditor or a regulator.

Confirm authoritative sources and identity keys
The registrar, HR and identity teams agree which system is authoritative for each population: students, faculty, staff, alumni, contractors and guests. They also agree a stable person identifier, the attributes that define program, department and employment status, and which system wins when two sources disagree. The output is a signed source-of-truth register that maps each attribute to one owner. Done means every attribute midPoint will act on has a named source and a named data steward.
Profile and clean the source extracts
Before any account is created, the team pulls sample extracts from the student information system and HR and checks them for duplicate person records, missing identifiers, conflicting status codes and records with no end date. Exceptions go back to the data owners for correction at the source, not inside midPoint. The output is a reconciliation report showing counts by population and each exception category. Done means the data owners have accepted the open exceptions or assigned them a remediation date.
Model roles from academic and employment status
Architects translate enrollment status, program, cohort, faculty appointment and staff job family into midPoint roles and assignment rules. Typical examples (illustrative) include an enrolled undergraduate in a program, a student on leave of absence who keeps identity but loses most application access, and a graduate who moves to an alumni role. Each role lists the target systems it grants and the approver who owns it. Done means every role has a documented owner, a rule that can be tested against sample people, and a short list of the entitlements it carries.
Find orphaned accounts before go-live
The team loads a read-only copy of each target directory and application through ConnId connectors, such as LDAP, Active Directory or SCIM2 where the system supports it, and compares those accounts with the authoritative population. Accounts with no matching person, accounts whose owner has left, and shared or service accounts are listed in separate queues. Owners decide whether each one is kept, linked, disabled or removed, and midPoint records the decision. Done means the orphan queues are empty or each remaining item has a recorded owner and a decision.
Run the semester start batch in test
Before the first live batch, the team replays a full semester start cycle against a test copy of the target systems. The run covers new enrollments, returning students, program changes, leaves of absence and graduations, and checks that each person receives the expected roles and no others. Failed cases are traced to the rule, the source attribute or the connector that caused them. Done means the replay matches the expected results for an agreed set of test people and the team has signed off the batch schedule.
Automate movers, leaves and graduations
In production, changes in the source systems drive midPoint reconciliation and provisioning. A program change removes the old program roles and adds the new ones. A leave of absence suspends selected entitlements while keeping the identity and any research access that the policy allows. A graduation moves the person to an alumni role with its own end date. The output is a provisioning log for each change that names the source event, the rule and the target action. Done means a sample of changes can be followed from source record to target account without manual steps.
Track guest and contractor accounts with end dates
Guest, visiting scholar and contractor identities usually come from a sponsor request rather than the student information system or HR. Each one is created with a sponsor, a business reason and a mandatory end date, and midPoint schedules disablement when that date passes. Expiring accounts generate a notice to the sponsor before the end date so that extensions are a decision, not a default. Done means every guest and contractor account has an end date and a sponsor, and no account is open-ended without an approved exception.
Reconcile and retain the evidence
On a schedule agreed with the data owners, midPoint compares the authoritative population with the accounts in each target system and records any drift. The reconciliation results, provisioning logs and approval records are retained for the period set by the institution's records policy and the applicable regulation. Compliance and privacy staff confirm which records count as education records for the purposes of 34 CFR Part 99 and what must be logged for disclosures. Done means the reconciliation reports are reproducible and the retention period has been confirmed in writing by the institution.

Which open source platforms fit a campus identity stack

A campus identity stack usually separates lifecycle governance from single sign-on, and each open source platform covers one of those layers. The cards below show where each platform fits, where it stops, and what to confirm against your student information system, HR source and campus directory before choosing.

midPoint for lifecycle and governance

midPoint handles the joiner, mover and leaver logic that connects the student information system and HR records to directories and applications, including access requests and certification campaigns. It is an identity governance platform, not an SSO server, so it does not issue OpenID Connect or SAML tokens. Check which target systems have a supported or community connector, since research platforms, library systems and learning tools often need custom work. Its long-term support release, 4.8 (Curie), is supported until 17 October 2028, which is a useful planning anchor for a multi-year campus rollout.

Keycloak for campus single sign-on

Keycloak provides the SSO layer for staff and student logins, with OpenID Connect, OAuth 2.0 and SAML 2.0 support, identity brokering and LDAP or Active Directory federation. Its supported production databases include PostgreSQL, MariaDB, MySQL, Microsoft SQL Server and Oracle Database, so confirm which one your operations team already runs. High availability needs a synchronously replicated database. Use the Operator with manual approval for updates, since the Operator documentation strongly recommends that mode to avoid unplanned upgrades during term time.

authentik, ZITADEL and FreeIPA as alternatives

These three platforms are alternatives to test against your directory, not default choices. authentik is MIT licensed except its enterprise directory, ZITADEL is AGPL-3.0 with SCIM and passkey support, and FreeIPA suits campuses that already run Kerberos and Linux identity. Each one changes how midPoint connects, so check whether the campus directory is Active Directory, LDAP or a mixed estate before committing. Ask each candidate how it handles student accounts with short lifecycles and how its upgrade path affects term schedules.

OpenBao for service account secrets

OpenBao suits service account and connector credentials, where midPoint and integration jobs need to read passwords or API keys without storing them in configuration files. It is licensed under MPL-2.0 and is hosted under the OpenSSF. Keep its scope narrow for education: student and staff login credentials belong in the directory and SSO, not in a vault. Confirm which systems can fetch secrets from OpenBao before you move the connector credentials out of existing configuration.

Vault is not open source

HashiCorp Vault from version 1.15.0 uses the Business Source License 1.1, with IBM named as licensor, and that license is not an OSI-approved open source license. If your campus policy requires open source components, treat Vault as a commercial dependency and check its terms with procurement before using it for connector secrets. Ask whether an existing Vault deployment in another department will be connected to the identity stack, because that would change the license review.

Deployment limits for research access and shared campus directories

Research computing often grants access to people who are not students or regular staff, such as visiting scientists, sponsored contractors and collaborators at other institutions. Their access usually rests on a sponsor, an end date and sometimes a data use agreement that limits which datasets they may see. Identity governance has to carry those attributes from the sponsoring department into the target systems, and it has to remove access when the sponsorship or agreement ends, even if the person still holds a campus account for other reasons.

Sponsor and expiry attributes: Model sponsor, end date and agreement reference as explicit attributes so that expiry can drive removal in midPoint rather than relying on a manual reminder.
Data use agreement scope: Map each agreement to a role or entitlement set so that access to restricted datasets is granted only while the agreement is active.
Connector coverage: Confirm which research storage, compute and project systems have a supported connector in the ConnId catalog. Systems without one need a documented manual or scripted path with its own evidence.
Sponsored account records: Keep the request, approval and end-date decision together so that FERPA-style records of who had access and why can be produced later, where research data includes student information.
Deployment placement: Run midPoint on a Linux virtual machine or from Docker images with PostgreSQL on a separate database server, and confirm that research connectors can reach the systems they manage through the network paths you permit.

Confirm with your research office which datasets are covered by agreements and which connectors your research systems already support before you finalize the role model.

Integration points and deployment pattern for a campus

A campus identity governance deployment connects a few authoritative sources, a set of target directories and applications, and one login front door. The cards below cover each integration point and the platform choices that affect how it runs in production.

Student information system feed

The student information system is usually the authoritative source for student joiners, program changes and withdrawals, so it drives most account creation and removal. Confirm which SIS events arrive as full extracts and which as incremental changes, and how the campus handles students who enroll late or return after a leave. A missed withdrawal event is the most common cause of lingering student access, so ask how the feed is reconciled against the SIS each term.

HR feed for staff and contractors

HR records govern staff, faculty appointments and contractor engagements, and their end dates should trigger removal. Contractors and affiliates often have no HR record, so decide early whether they come from a separate sponsor-driven source. Check how terminations, rehires and concurrent appointments are represented, because a single person with two roles needs a clear precedence rule in midPoint.

Directory connectors through ConnId

midPoint reaches directories and applications through the ConnId connector framework, with documented connectors for LDAP, Active Directory, SCIM2 and Microsoft Entra ID. Confirm that each campus system you need has a supported connector rather than a community or experimental one, and test write, read and delete operations against a non-production copy before go-live. Ask who owns connector upgrades when the directory vendor changes its API.

SSO federation with the login server

midPoint does not act as the SSO server, so the campus needs a separate login service that issues OpenID Connect or SAML tokens to applications. Keycloak is one option that supports both protocols along with LDAP and Active Directory federation. Decide which system is the source of record for passwords and MFA enrollment, and confirm that deprovisioning in midPoint revokes sessions and not only directory entries.

Keycloak Operator on Kubernetes

The Keycloak Operator, installed through Operator Lifecycle Manager, manages the Keycloak server and realm, client resources as custom resources. Set the operator to manual approval mode so that a cluster update cannot change the login service during term start. Plan schema migration explicitly: Keycloak migrates its database automatically at startup by default, but large deployments can apply the SQL themselves under change control.

Database high availability with synchronous replication

Both supported Keycloak high availability designs require a synchronously replicated database, so the database layer is the component most likely to be under-specified. Ask the campus infrastructure team which PostgreSQL or other supported database engine it operates, how failover is tested, and whether replicas span availability zones. An asynchronous replica that loses writes during failover can leave a deprovisioning or session change unapplied, so verify the replication mode before choosing a topology.

What auditors and the Department of Education ask for

This table lists the evidence an auditor or Department of Education reviewer is likely to request for an education identity program, the component that produces each item, and what to confirm before relying on it. Read each row as a question to answer with a record from your own environment, not as a guarantee of how an examiner will judge it.

Evidence item	What it shows	Component that produces it	What to confirm
Provisioning approvals	Who approved access to student information, finance and research systems before the account was created	midPoint request and approval workflow records and audit log	Approval records are retained for the same period as the access they cover, and approvers are named
Removal timestamps for leavers	When a graduating student, departing staff member or ended guest lost each entitlement	midPoint audit records for account and entitlement changes, plus connector logs from each target system	Removal in every connected system is logged, including systems that were not connected through midPoint
Access review decisions	Which reviewer kept, changed or removed each entitlement during a certification campaign	midPoint certification campaign records	Reviewers are accountable owners, and campaign scope covers research and alumni access as well as staff
FERPA access and disclosure records	Each request for, and disclosure of, personally identifiable information from education records, with the party and legitimate interest	Application logs and audit records in the systems holding education records, combined with the institution's own disclosure register	Identity logs alone do not satisfy the record requirement, so confirm which system records each disclosure
MFA configuration for systems reaching customer information	Which accounts reaching financial aid or other GLBA-scoped data must use multi-factor authentication, and how it is enforced	Keycloak realm and authentication flow configuration, exported and version controlled, with admin events for changes	Target applications that do not sit behind the SSO server are covered by a separate control
Administrative change history	Who changed roles, realms, clients or authentication settings in the identity platform	Keycloak admin events and midPoint audit records	Admin event storage is enabled and retained for the required period
Operational monitoring	Whether authentication failures, service availability and provisioning errors were watched and acted on	Keycloak metrics exposed for monitoring, and midPoint task and error reports	Alert thresholds and response records exist, not only dashboards
Written information security program	The policies, roles and risk assessments that govern the identity program under the Safeguards Rule	Institution-owned policy documents, with DeployOpen supplying technical runbooks and configuration baselines	A named program coordinator and a current risk assessment are documented by the institution

How a campus identity rollout is phased

The sequence moves from clean source data and a agreed role model to a tested midPoint build, a full semester of parallel running, and a cutover timed before the semester start peak, ending with the first certification campaign as evidence.

Inventory sources and review data quality
DeployOpen and the college's registrar, HR, IT and library owners list every authoritative source: the student information system, HR, the directory, and any guest or alumni databases. Each source is checked for duplicate person records, missing identifiers, stale statuses and conflicting job or enrollment codes. The output is a signed source register that names the system of record for each identity attribute and a cleanup list with owners. The step is done when every source has a named owner and the cleanup backlog is accepted in writing.
Build the role model from existing access
Current entitlements are exported from the directory, learning management, library, research storage and key applications, then grouped by the roles people actually hold, such as enrolled student, teaching staff, research staff, alumni and guest. Application owners confirm which bundles match real job functions and which access is historical. Research group and sponsored access are modeled separately so that they can be kept during deprovisioning. The output is a draft role catalog with an owner for each role, reviewed by the business owners. The step closes when the catalog is approved and the exceptions list is documented.
Build and test the connectors
midPoint is configured with its authoritative feeds and connectors to the target systems, using the ConnId framework to reach directories, databases and SCIM-capable applications where those connectors are supported. Joiner, mover and leaver rules are coded against the role catalog, and each connector is tested in a non-production environment with sample identities. Results are compared against the expected accounts and entitlements for every test case. The output is a test report showing each rule, its expected result and its actual result, and any connector that is community or experimental is flagged for a decision. The step is done when the test cases pass and open defects are assigned.
Run a parallel semester cycle
midPoint runs alongside the existing provisioning process for one full academic cycle, so the team can compare what midPoint would have done with what staff actually did. Discrepancies are logged by cause, such as bad source data, missing rules or unmanaged local accounts, and fixed in the source or the rule set. Research access and guest accounts are monitored closely during this period. The output is a reconciliation record showing agreed differences and a signed go-live decision from the IT and registrar leads. The step is done when the discrepancy count has been reviewed and each open item has an owner.
Cut over before the semester start peak
Provisioning authority moves from manual or legacy processes to midPoint in a planned change window, with a rollback procedure written and rehearsed beforehand. The most sensitive populations, such as incoming students, staff with elevated roles and external researchers, are verified first. Monitoring and alerts are reviewed on the first days of the semester, when account volume is highest. The output is a cutover record with the verification results and the rollback decision point. The step is done when the first high-volume intake completes with no unresolved failures.
Run the first access certification campaign
The first campaign asks managers and resource owners to confirm the access their staff and students hold, using the role catalog and entitlement reports from midPoint. Reviewers' decisions, reminders and any revocations are recorded and linked to the underlying entitlements. Results are reviewed for orphaned accounts, excess access and unanswered reviews, which are escalated. The output is a campaign report with decision records that the institution can retain as evidence. The step is done when every campaign item has a recorded decision or an escalation.

Deprovisioning without breaking research access

The institution and its research office own the decisions in this section: who may sponsor a research account, how long it stays active, and which research data a departing person keeps. An identity governance platform such as midPoint enforces those decisions but does not make them. Model sponsored research accounts, emeritus faculty, visiting scholars and external collaborators as their own identity types, each with a named sponsor, a start date and a mandatory end date. Without a sponsor and an end date, a visiting scholar account quietly becomes permanent, and the first time anyone reviews it the institution cannot say who approved it or why it still exists.

When a staff member or student leaves, separate the campus-wide removal from the research decision. Campus systems such as email, the learning platform, the library and building access can be removed on the leaver event driven from HR or the student information system. Research data permissions, shared project storage and lab systems should instead move to a review queue owned by the principal investigator or the research office, with a deadline agreed in advance. Confirm with your research office which systems hold grant-funded data, which hold sensitive records, and whether a sponsor can take over a project account before the original holder leaves. Record each decision so that the retained access can be explained later.

Before go-live, ask your implementation partner to show how sponsor relationships are stored in midPoint, how an expiring sponsored account is suspended or disabled before it is deleted, and how a sponsor is asked to re-confirm the account at regular intervals. Confirm that the retention rules for these records match your institution's policy on research records and any applicable grant terms. Also confirm which target systems can disable an account without deleting the data it owns, since that difference determines whether research access can be restored after a short gap.

What do campuses ask before hiring an identity partner?

What drives the cost of an open source identity governance project for a university?

The main cost drivers are the work, not a license fee. midPoint is published under open source licenses and Evolveum states it has no enterprise edition, so there is no per-user software charge to budget. The cost is connector work for each target system, role modeling from existing access, cleanup of the student and staff data that feeds the project, infrastructure to run midPoint and its PostgreSQL database, and support. Connector and role work rise with the number of systems, such as the student information system, learning management, library, research storage and Active Directory. Ask any partner for a fixed-scope quote that lists each connector, each role family, the cleanup work and the support terms as separate line items.

How long does it take to reach a first cutover on campus?

The duration depends on how many authoritative sources and target systems are in scope and how clean the source data is. A first cutover usually starts with one source, such as the student information system for students or HR for staff, and a small set of targets. Campuses should ask a partner to give the timeline in the written scope, with milestones for source mapping, connector build, parallel run and cutover, and to name what the campus must provide at each step. Avoid committing to a cutover date before the orphaned and duplicate accounts have been reviewed, because those records decide how much reconciliation the first run needs.

What must university staff supply before an identity partner starts work?

The partner will need access to people and records, not only technical access. Expect to supply named owners for the student information system, HR, Active Directory or LDAP, learning management and research systems, plus extracts or test access to each. Registrar and HR staff should confirm how student status, program enrollment, appointments and terminations are recorded, since those codes drive joiner, mover and leaver rules. Research computing and library owners should list the group or project memberships that must survive a leaver event. Ask the partner for a written list of required inputs before kickoff so the campus can plan owner time.

Can our team operate midPoint without the partner after go-live?

Many campuses can run midPoint with internal staff, but it requires Java and PostgreSQL skills, change control for connector configuration, and someone who understands the role model. midPoint recommends Java 25 for version 4.11 and later and Java 21 for version 4.10 and older, and it uses PostgreSQL ideally on a separate database server. Evolveum offers Product Support and Platform Subscriptions, which are separate from any implementation partner. DeployOpen provides ongoing support, upgrades and documentation as retainers. Ask the partner which runbooks, handover sessions and admin training are included in the fixed scope, and which parts stay with the campus.

How does an identity governance system handle the fall semester peak?

Semester starts create a large batch of joiners, enrollment changes and class-based access within a short window, so the design must handle bulk events without slowing normal operations. Ask how the partner will schedule large reconciliation runs, whether midPoint task scheduling is sized for the expected volume, and how multi-node deployments are configured, since midPoint documents a sticky HTTP load balancer, a shared central database and Quartz for distributed task scheduling. Also ask for a rehearsal against a copy of the production data before the first peak, and a rollback plan for a bad source extract.

Do we have to replace our single sign-on server to use midPoint?

No. midPoint is an identity management system, not an access management or SSO server, and Evolveum states it does not implement the server side of OAuth2, OpenID Connect or SAML. midPoint provisions accounts and entitlements into target systems, and an existing SSO server or directory continues to handle sign-in. Its own user interface can authenticate against an external SSO service. Confirm with the partner how midPoint will sit beside your current SSO, which directory it writes to, and whether any login changes are needed for research and guest access.

Will removing leavers from midPoint break research access and alumni accounts?

It can, if leaver rules treat every status change the same way. Research collaborations, emeritus faculty, alumni services and guest accounts often depend on group or project membership that is not tied to an active appointment. Before go-live, ask the partner to map each population to a documented rule, to set grace periods and sponsor-based extensions where the policy requires them, and to test the removal path against research storage and collaboration tools in a non-production environment. Ask who approves exceptions and how each exception is recorded.

Which student privacy rules shape the scope of the identity project?

FERPA's regulations in 34 CFR Part 99 apply to institutions that receive funds from a program administered by the US Secretary of Education. Under 34 CFR 99.31, a contractor may receive education records as a school official only under defined conditions, and the institution must use reasonable access controls so staff see only the records in which they have a legitimate educational interest. The institution must also keep a record of disclosures under 34 CFR 99.32. Confirm these obligations with your counsel and privacy office, and ask the partner to design role-based access and audit logging that supports them.

Questions to ask an implementation partner about campus identity

Start with the source of truth. Ask the partner how they model the student information system and HR as authoritative sources, which attributes each feeds, and who decides when the two disagree about a person who is both a staff member and a current student. Ask for a sample mapping of one student lifecycle event, such as an applicant becoming an enrolled student, and one for a graduate who keeps a research appointment. Ask which midPoint connectors they have deployed in production for directories, the student system and research platforms, not only which ones appear in the connector catalog. Ask how they will handle the school official test for contractors: whether the partner's own engineers will see education records during implementation, how that access is limited to the work scope, and how the institution keeps direct control over the records, as described in 34 CFR Part 99.

Ask how orphaned and stale accounts are found and cleared before go-live. A credible answer names the reconciliation run against each target directory, the rules for accounts with no authoritative owner, the approvals needed before disabling or deleting, and the retention period for accounts from prior years. Ask how a semester start peak is rehearsed: whether the partner loads a realistic volume of enrollments into a non-production copy, measures how long the batch takes, and reruns the job from a clean state. Ask who approves the change window and who is on call when the first cohort of accounts is created. Confirm that the partner has a written plan for a failed run.

Ask how midPoint upgrades are planned against support end dates. Evolveum's midPoint releases page lists support end dates for each line, and the partner should show which line the campus runs today, when it reaches end of support, and how the upgrade is staged through test and recovery environments. Ask how access reviews are evidenced: which campaign definitions run each term, who reviews guest and research accounts, how decisions and reviewer names are stored, and how an auditor would sample a population of students or contractors. Ask who keeps those records and for how long, and how they match the institution's records retention rules. The answers to these questions should go into the statement of work before any work starts.

Open source identity governance for education