The identity market likes clean categories.

• Employees belong in Workforce IAM.
• Customers belong in CIAM.
• Access reviews belong in IGA.
• Login and MFA belong in Access Management.
• Service accounts and AI agents belong in Non-Human Identity.

That structure may work for analyst reports and vendor comparison grids. It does not work as well in the real world.

Higher education proves why.

Few environments expose the weakness of traditional identity categories more clearly than the student identity lifecycle. A student is not simply an internal user. A student is not simply a customer. A student is not simply an external user. A student may be all of those things at different points in time, and sometimes more than one at once.

That complexity makes higher education one of the clearest examples of why the identity market needs to move beyond rigid workforce and CIAM categories.

The student identity problem is not a higher education edge case. It is a preview of where identity management is going.

A Student Is Not Just a Student

At first glance, student identity sounds simple.

A person applies to an institution, becomes a student, receives access to systems, and eventually graduates.

In reality, the lifecycle is much more complicated.

A person may begin as a prospect, become an applicant, be admitted, become an enrolled student, work part-time for the institution, conduct research, participate in athletics, receive financial aid, use healthcare services, graduate, become alumni, donate to the institution, return for another degree, later teach as adjunct faculty, or come back as a contractor or guest.

Those are not just status changes. They are relationship changes.

Each relationship may have a different source of authority, access requirement, ownership model, risk profile, and governance obligation.

The institution is not managing one static student account. It is managing an evolving set of relationships between the individual and the institution.

Why Workforce IAM Does Not Fully Fit

Workforce IAM is typically built around institutional employment.

The authoritative source is often HR. Access is commonly driven by job, department, manager, location, employment status, and role. Lifecycle events are usually tied to hire, transfer, leave, and termination.

That model is important, but it does not fully describe the student lifecycle.

Students are not employees in the traditional workforce sense. Their relationship may begin before enrollment. They may need access before they are officially active students. Their access may change based on admissions status, enrollment status, academic program, housing, financial aid, research involvement, athletics, or campus services.

Then the same person may become a student employee.

Now the institution has both a student relationship and an employment relationship tied to the same individual.

If the student job ends, should the student account be removed? No.

If the student withdraws but remains an employee? The answer may also be no.

If the student graduates, should all access disappear immediately? Not necessarily. Alumni services, transcripts, email, donor systems, career services, and continuing education access may still apply.

Workforce IAM alone does not fully capture that nuance.

Why CIAM Does Not Fully Fit

CIAM is often associated with external users, customer registration, consent, privacy, user experience, and digital engagement.

That may sound closer to parts of the student journey, especially admissions, portals, alumni services, parent access, or continuing education. But students are not simply customers either.

They may have regulated access needs, institutional obligations, academic records, financial aid processes, housing systems, health services, research access, campus safety considerations, and role-based access to internal systems. The institution must manage more than a pleasant login experience. It must manage lifecycle, policy, governance, risk, affiliation, and access across many systems.

A student may self-initiate some part of the relationship, but the institution still needs to govern that relationship with precision.

CIAM alone does not fully capture that nuance either.

The Student Lifecycle Breaks the Categories

The student identity lifecycle sits in the middle of multiple identity categories.

• It has characteristics of CIAM because it may include external engagement, self-service, account claim, consent, digital onboarding, and identity verification.
• It has characteristics of Workforce IAM because students may become employees, researchers, assistants, or workers with internal access needs.
• It has characteristics of IGA because access must be reviewed, governed, justified, and removed when no longer appropriate.
• It has characteristics of Access Management because authentication, SSO, MFA, and password management are central to the user experience.
• It has characteristics of Partner and Guest Identity because students may participate in external collaborations, cross-institution programs, research partnerships, and temporary affiliations.
• It may also intersect with Non-Human Identity because students, researchers, faculty, applications, labs, integrations, and AI-enabled tools increasingly rely on service accounts, workloads, and delegated access.

So where does student identity belong?

The answer is: it does not belong cleanly in one category. It belongs in a relationship-aware identity model.

The Real Problem Is Relationship State

The real identity question is not “Is this person a student, employee, customer, or guest?”

The real question is:

What relationship does this person currently have with the institution, and what should that relationship allow?

That requires understanding relationship state.

• A prospect should not receive the same access as an admitted student.
• An admitted student may not need the same access as an enrolled student.
• An enrolled student may not need the same access as a student worker.
• A student worker should not lose academic access when employment ends.
• An alumni may retain certain services but lose access to active student systems.
• A parent may receive delegated access to specific information but should never become the student.
• A visiting researcher may require temporary access tied to sponsorship, duration, and project scope.
• A service account supporting a student-facing application needs ownership and lifecycle governance just like any other managed identity.

Each of these scenarios depends on relationship context.

Without relationship context, access decisions become fragile, manual, inconsistent, or overly broad.

Higher Education Shows the Cost of Disconnected Identity

When identity is handled through disconnected systems, higher education institutions often end up with fragmented processes.

• Admissions may create one identity process.
  The student information system may drive another.
  HR may drive another.
  Alumni systems may create another.
• Guest access may live somewhere else.
  Parent access may follow a separate path.
• Research access may be handled manually.
  Service accounts may be tracked in spreadsheets.
• Access reviews may happen in a separate governance tool.
  Authentication may be managed by yet another platform.

Each system may make sense in isolation. The problem is that the person does not exist in isolation.

The same individual may move across these relationships over time, and the institution must understand the full picture.

When it cannot, the result is familiar:

• Duplicate accounts
• Orphaned access
• Manual exceptions
• Delayed onboarding
• Poor student experience
• Help desk burden
• Role accumulation
• Inconsistent deprovisioning
• Audit gaps
• Unclear ownership
• Increased security risk

This is not just an IT inconvenience. It is an institutional risk and experience problem.

Why This Matters Beyond Higher Education

It would be easy to dismiss student identity as a higher education-specific issue. That would be a mistake. The same pattern is showing up everywhere.

• Healthcare organizations manage patients, employees, providers, contractors, volunteers, researchers, vendors, service accounts, and affiliated clinicians.
• Financial services organizations manage customers, employees, advisors, auditors, third-party providers, partners, and regulated access roles.
• Manufacturing organizations manage employees, plant workers, contractors, suppliers, distributors, dealers, customers, applications, and machine identities.
• Government organizations manage employees, citizens, contractors, agencies, vendors, temporary workers, and delegated administrators.
• Retail organizations manage customers, employees, loyalty members, suppliers, franchisees, seasonal workers, contractors, and service accounts.

The labels change, but the underlying problem is the same.

• Identity is no longer static.
• Relationships overlap.
• Access changes over time.
• Governance must follow the relationship.

Higher education simply makes the problem impossible to ignore.

The Future Is Relationship-Aware Identity

The student identity problem proves that the market is asking the wrong question when it tries to force identity into narrow categories.

The future is not simply workforce IAM versus CIAM. The future is relationship-aware identity.

A relationship-aware identity model understands that an identity may represent many relationships over time. It recognizes that access should be based on relationship context, lifecycle state, ownership, policy, and governance.

That model allows an organization to answer better questions:

• What relationships does this person or entity currently hold?
• Which systems are authoritative for each relationship?
• Which access rights are tied to each relationship?
• Who owns or sponsors the relationship?
• What happens when one relationship ends but another remains active?
• What access should be retained, changed, reviewed, or removed?
• How do we govern human and non-human identities consistently?

That is the model modern organizations need.

Code-Free Configuration Is Critical

Relationship complexity should not require custom code.

If every new population, lifecycle change, exception path, access rule, or governance process requires development work, the identity program becomes brittle. Higher education has shown this for years. Institutions change programs, processes, systems, policies, and populations constantly. Identity must be able to adapt.

That same need now exists across industries.

A relationship-aware identity platform should allow organizations to configure:

• Relationship types
• Lifecycle states
• Authoritative sources
• Ownership and sponsorship
• Access rules
• Approval paths
• Expiration and renewal logic
• Authentication requirements
• Governance reviews
• Deprovisioning actions
• Exception handling

Complex identity should be modeled, not hard-coded.

The Fischer Identity Perspective

At Fischer Identity, we believe the student identity problem reveals a much larger truth about the identity market.

Organizations are not just managing users. They are managing relationships.

Fischer Identity supports complex identity populations through one configurable, code-free lifecycle and governance platform. That includes workforce, student, applicant, contractor, guest, vendor, partner, alumni, parent, customer-like, service account, non-human identity, and future AI agent scenarios.

Higher education has proven the model because it demands support for overlapping, changing, and recurring relationships at scale.

But the broader market is heading in the same direction.

Organizations need identity platforms that can manage every relationship across its lifecycle, not force every identity into a narrow category.

One Platform. Every Relationship. Continuous Identity Control.

The student identity problem proves the market is wrong when it treats workforce IAM and CIAM as cleanly separated worlds.

Real identity is more complex.

• A student may be an applicant, worker, researcher, alumni, donor, guest, or future employee.
• A customer may become an employee.
• A contractor may become a partner.
• A service account may outlive its owner.
• An AI agent may need lifecycle governance from day one.

The identity market may be organized around categories, but organizations operate through relationships.

Every identity is a relationship. Every relationship has a lifecycle. Every lifecycle needs governance.

That is the foundation of relationship-aware identity. And it is why modern organizations need one platform, every relationship, and continuous identity control.