Key takeaways
-
Single sign-on solves authentication convenience, one login for many services, but it does not by itself solve access governance, which is the separate question of whether the right person still has the right level of access to the right system.
-
NIST's digital identity guidelines treat multi-factor authentication as the baseline for any system holding sensitive data, and research measuring higher education's actual compliance with these guidelines has found widespread but incomplete adoption, particularly around session and credential lifecycle practices.
-
Every application connected to campus SSO, whether provisioned by IT or adopted by a department on its own, is a door into the same identity system, and a CIO who cannot produce a current list of every connected application has an access governance gap, not just an SSO configuration.
Why identity and access is the governance layer under every other system
Every workflow this institution runs, financial aid verification, grade changes, IACUC protocol review, FERPA disclosure logging, depends on one underlying assumption: that the person taking the action is who the system says they are, and that they are authorized to take that specific action. Identity and access management is not a separate IT project sitting next to everything else. It is the layer every other governance conversation on campus quietly depends on, which is exactly why a gap in it does not show up as an identity problem. It shows up as a FERPA disclosure nobody can attribute, a grade change nobody can verify came from the instructor of record, or a vendor application still holding institutional data a year after the department that adopted it stopped using it.
What SSO and federated identity actually solve, and what they don't
Federated single sign-on, typically built on SAML-based identity federation through InCommon, lets students, faculty, and staff use their home institution credentials to authenticate across dozens or hundreds of connected services without maintaining separate passwords for each one. That solves a real problem: password fatigue, weak reused passwords, and the support burden of resetting credentials for every disconnected system a department adopts on its own.
What SSO does not solve is access governance. A student who graduates, an employee who changes roles, or a vendor contract that ends does not automatically lose access to every system just because SSO is in place. SSO controls how someone proves who they are. It does not, on its own, answer whether they should still be allowed in.
Where MFA and NIST guidance actually bind higher education
NIST's Digital Identity Guidelines treat multi-factor authentication as the practical baseline for achieving a meaningful assurance level in digital authentication, particularly for any system holding sensitive institutional or personal data. Independent research measuring policy compliance across more than a hundred higher education institutions found widespread but incomplete MFA deployment, with the more consistent gaps showing up in password expiration practices, password composition rules, and credential lifecycle management rather than MFA adoption itself.
The practical reading for a CIO: MFA adoption is usually the visible, already-addressed piece. The quieter gap is what happens to access after authentication succeeds, whether a departing employee's access is actually revoked promptly, whether a vendor's access is time-boxed to the life of the contract, and whether anyone can produce a current answer to "who can access this system right now" without a manual audit.
Identity governance models compared
|
Model
|
What it controls
|
What it leaves open
|
|
Local accounts per system
|
Nothing centrally; each system manages its own credentials
|
No single view of who has access to what; offboarding requires touching every system individually
|
|
SSO / federated identity (SAML, InCommon)
|
Authentication: one credential across connected services
|
Authorization: whether that person should still have access to a specific connected app
|
|
SSO with MFA enforced
|
Authentication plus a stronger assurance level on the credential itself
|
Access lifecycle: provisioning, review, and timely deprovisioning as roles change
|
|
Governed access with review workflow
|
Who has access, why, and when it was last reviewed, across every connected application
|
Requires a workflow layer most SSO and MFA deployments were not built to provide on their own
|
A governed identity and access review workflow
Every connected application inventoried
Any system tied into campus SSO, IT-provisioned or department-adopted, is logged in one place, closing the gap where a CIO cannot name every application actually connected to the identity system, several of which likely rely on the school official exception to access student data at all.
Access requests routed through a defined approval
Provisioning access to a new system requires an approval tied to role and legitimate need, rather than an informal request to whoever manages that system.
MFA and assurance level enforced consistently
Systems holding sensitive data are flagged for the authenticator assurance level NIST's guidelines call for, rather than left to whichever configuration the connecting application defaults to.
Access reviewed on a schedule, not on discovery
Who has access to what is reviewed periodically rather than only surfacing during an audit or a security incident.
Deprovisioning triggered by the same event that ends the need
A role change, a graduation, or a vendor contract ending triggers access removal automatically, instead of depending on someone remembering to file a ticket.
Every access grant and revocation logged
The record of who had access, when, and why is retained and producible on demand, the same evidentiary standard applied to any other governed institutional process.
Portals and login flows checked for accessibility
Any identity or access portal a student or employee uses is itself in scope of Title II web and app accessibility requirements, which a workflow review can flag alongside its security posture.
Kissflow and the identity and access governance stack
Kissflow is the governed execution layer at the edges of the identity and access stack. It does not replace the identity provider that handles SSO authentication or the SAML federation that connects campus systems. It replaces the manual tracking, or the absence of tracking, around who requested access to what, who approved it, and whether it was ever reviewed or revoked.
If your institution runs an established identity provider with SSO and MFA already in place, Kissflow does not compete with that infrastructure. It sits alongside it as the access governance layer: routing provisioning requests through defined approvals, flagging systems that should carry stronger authentication requirements, and running the periodic access reviews that most institutions currently do not run at all, because SSO adoption is often mistaken for access governance being solved. Every connected application, including Kissflow itself, is a vendor worth vetting through a standard review such as the Higher Education Community Vendor Assessment Toolkit, backed by independent controls documentation such as SOC 2.
The differentiation that matters to a CIO: when a new application connects to SSO, or an access review policy changes, the office that owns identity governance updates the workflow directly, instead of discovering months later, during an audit, that nobody has reviewed who still has access to a system the institution stopped actively managing.
Frequently asked questions
-
Does SSO mean an institution's access governance is already handled?
No. SSO solves authentication, proving who someone is with one credential across many systems. It does not solve authorization, the ongoing question of whether that person should still have access to a specific system. Those are different problems that require different controls.
-
What does NIST actually require for multi-factor authentication in higher education?
NIST's guidelines are not a law that binds institutions directly, but they set the practical standard for achieving a meaningful authentication assurance level, and institutions handling sensitive data are generally expected to meet it. Research shows most institutions have adopted MFA broadly, with the more common gaps appearing in password and credential lifecycle policies.
-
Why does deprovisioning matter as much as provisioning?
An account that is never removed after someone leaves, changes roles, or a vendor contract ends is a standing access risk nobody is actively monitoring. Provisioning gets attention because someone is waiting for access. Deprovisioning gets missed because nobody is waiting for its absence.
-
Can a department connect its own tool to campus SSO without IT's full involvement?
Often yes, technically, which is exactly the governance gap. SSO connection is a technical integration step; it is not the same as an access review confirming the connection was appropriate and remains appropriate over time.
-
Does Kissflow replace our identity provider or SSO infrastructure?
No. Kissflow governs the access requests, approvals, and reviews around the identity infrastructure you already run. The identity provider and SSO federation remain exactly where they are.
Request a 30-minute walkthrough to see how Kissflow governs access requests, reviews, and deprovisioning across every application connected to your campus identity system. Book a demo today.
