Catalyst to Catalyst (Fall 2026): Ideas and Insights from InCommon Catalysts

Edited by Apryl Motley, CAE – Communications & Technical Writing Consultant

As part of our ongoing commitment to providing you with additional opportunities to benefit from the insights and expertise of InCommon Catalysts, we are continuing their quarterly Q&A column, Catalyst to Catalyst, which we feature in our e-newsletter InCommon News.

Think of Catalyst to Catalyst as a quarterly virtual advice panel that provides perspectives on key identity and access management (IAM) topics for the InCommon community. In this installment, catalysts discuss innovative approaches to lifecycle management and emerging technologies. This is our third column for 2026.

Question: What effective or innovative approaches to lifecycle management have you implemented or observed recently?

Response: The most useful lifecycle work we have done lately has not been about the joiner/mover/leaver logic itself. That part is well understood. It has been about the edges:

• Populations that do not fit the model
• Places where lifecycle automation fights the security tooling
• Systems the identity governance and administration (IGA) platform cannot reach

Student workers are the classic example of the first lifecycle — one person, two overlapping affiliations, and two systems of record (HR and the student information system) that do not agree on when the person started or stopped.

Most institutions handle this by picking one source as the winner and living with the gaps. On a recent SailPoint identity security cloud (ISC) build for a university, we took a different route.

Instead of modeling the whole thing in the connector, we built a workflow in ISC that hands the hard decisions to an external endpoint the university owns (a small PowerShell service in this case). The IGA platform detects the change and orchestrates; the endpoint applies the local rules about which affiliation wins and when, and the answer comes back as a plain attribute.

It is nothing exotic, but it keeps the institution’s business logic somewhere their own staff can read and change it without a vendor engagement.

The second example is one we have seen at three separate institutions. Microsoft Defender detects a compromised account and disables it in Entra. The IGA platform, which believes the user is active because HR says so, notices the account is disabled and helpfully re-enables it. This repeats until someone notices.

The fix we settled on is to check the Entra audit log for that user before any re-enable operation. If the disable came from Defender, the identity gets flagged as compromised, and the lifecycle process leaves the account alone until security clears it. Lifecycle automation should know when to stop, and by default, it doesn’t.

The third approach is for systems that don’t work for cross-domain identity management (SCIM), lightweight directory access protocol (LDAP), or anything a cloud IGA can communicate with. Every campus has something like a department database from 2009, a flat file the library system consumes, or a homegrown application nobody wants to touch. These artifacts are exactly where deprovisioning fails because the lifecycle process ends at the last connector.

We have been building a SCIM 2.0 gateway that sits in front of these systems (Java database connectivity, LDAP, delimited files, secure shell, representational state transfer) and presents a spec-correct SCIM interface to whatever IGA or identity provider is upstream. It’s not a new idea. However, doing it strictly to requests-for-comments 7643/7644 matters, since many “SCIM” endpoints in the wild are not, and the gateway ends up doing double duty normalizing them.

None of this is innovative in the sense of new technology. It is innovative in the sense that it extends lifecycle management to the parts of the campus where it has never actually worked and teaches it to get out of the way when it should not be working at all.

Question: What’s one emerging technology (besides AI) that you think research and education would benefit from implementing sooner rather than later?

Response: Higher education has an identity-proofing problem; it affects entire populations, but we are treating it at each step in the student registration process, or one step for each desk. Students prove who they are at the admissions counter, then at the registrar, then at the health center, then at the door of a federal research enclave, and even at the help desk when they are trying to reset their passwords.

This means that at any time, several teams are looking at the same documents, scanning them into a database, reviewing material, and making a judgment call. If you have ever spent some time visiting a government service building, you understand this frustration all too well. So why do we make students do this when other options are available?

As of this writing, 22 states and territories issue mobile driver’s licenses (mDLs). Although the overall adoption rate of this credential is uneven, one can reasonably assume that adoption rates will continue to rise each year.

It may have seemed like science fiction only a few years ago, but the NIST National Cybersecurity Center of Excellence has already drafted its mDL practice guide, and the ISO 18013 standards have enough traction that we can build against them. The draft offers a reference architecture that supports the adoption of “verify but do not retain” measures by higher education institutions. Students present their credentials signed by the issuing authority, and we can verify them against a trusted issuer list rather than squinting at a JPEG or trying to determine whether the picture on their phones (which has likely locked twice since they were at the counter) is accurate.

Despite the general “newness” of this credential, it is more secure than we might give it credit for. We ask people to email photographs of their licenses, passports, and birth certificates. We would like to think they are accurate, but with modern AI tools, spoofing them is not as difficult as it once was.

Even with valid photos, what do we do with them? They sit on shared drives and in ticketing systems and may never be viewed again. Meanwhile, a wallet is cryptographically verifiable and can be confirmed without ever receiving the document.

But this brave new world is not without its dangers. For a system like this to succeed, it must be built with intentionality. Here are a few key items to consider:

1. Make it an acceptable input, not the only one: Adoption is uneven, and most international students will not have an mDL. Presenting a wallet could be an additional option, alongside document review and in-person proofing, rather than a replacement for these processes.

2. Verify once, then get rid of it: Keep the assertion that the person was proofed, at what assurance level, and on what date. Do not keep the data; you are simply recreating the problem you are trying to avoid.

3. Ask for the attribute, not the document: Selective disclosure is a great system, but only if the request is properly scoped. Most campuses just need to validate certain parts of the person’s record, not the entire thing.

The big question is: why move on this now? If you are like most campuses, you are already rebuilding your identity-proofing workflows to combat ghost students and financial aid fraudsters.

Coupled with the fact that the National Institutes of Health controlled-access compliance deadline is January 2027, this means you can take additional steps now to add options, such as mDLs, and prepare before the mandate takes effect. You are adding anti-fraud layers while making things easier for your students. This also positions your institution to pass federal research enclave audits ahead of the mandate.