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

Question: How can institutions determine the right identity proofing approach?

Response: Institutions can determine the right identity proofing approach by shifting from a one-time onboarding mindset to a risk-based, lifecycle-driven model where identity proofing is applied dynamically based on who the users are, what they are accessing, and when that access occurs.

Instead of enforcing uniform proofing across all users, leading institutions align assurance levels (e.g., REFEDS IAP Low/Medium/High) to access sensitivity, identity confidence, and privilege, invoking proofing only at key lifecycle triggers, such as onboarding, access escalation, or identity ambiguity. 

By embedding proofing outcomes directly into identity and access management/identity governance and administration (IGA) decision-making (rather than treating them as standalone checks), institutions can reduce friction, improve trust in identity data, and enable more precise, risk-aware access control.

Here are several actionable steps institutions can take:

1. Define risk-based assurance tiers by mapping access types (general, regulated, privileged) to assurance levels (low, medium, high), and align them with standards such as REFEDS RAF.

Example: General campus systems (e.g., learning portals) require low assurance, while access to financial systems or research data requires medium or high assurance aligned to federated standards.

2. Identify key lifecycle proofing triggers by applying proofing at critical events, such as onboarding, access elevation, identity conflicts, and credential recovery.

Example: A new hire is verified during onboarding but must complete step-up proofing again when promoted to a privileged IT role or when resetting credentials after an account lockout.

3. Segment identity populations by tailoring proofing requirements based on user type and risk level.

Example: Students are verified through student information system (SIS) enrollment, employees through HR onboarding, and affiliates or vendors may require sponsor approval or ID validation if no authoritative record exists.

4. Apply lighter proofing for low-risk access and step-up proofing for higher-risk scenarios.

Example: A student accessing course materials needs only basic verification, while a finance employee or system administrator must complete multi-factor authentication (MFA) enrollment or ID verification before gaining sensitive access.

5. Integrate proofing into IGA workflows by storing assurance levels as identity attributes and use them to automate access decisions.

Example: A user tagged as “high assurance” can request access to sensitive data, while “low assurance” users are restricted or flagged during access reviews until re-verified.

6. Leverage authoritative sources by using trusted systems (HR, SIS) as the primary identity validators and strengthen proofing where those sources do not exist.

Example: Employees and students are trusted based on HR and SIS data, while contractors not in these systems must provide government ID or obtain manual approval before accessing systems.

7. Adopt a phased implementation model by starting with onboarding, then expanding to event-driven and high-risk scenarios over time.

Example: Begin with identity verification at account creation, then introduce step-up proofing when users request administrative or regulated system access, eventually extending to federated assurance alignment.

8. Minimize user friction by applying proofing only when risk justifies it.

Example: Use step-up or event-driven verification instead of blanket enforcement.

9. Continuously evaluate and refine by monitoring operational data and adjust assurance levels and triggers accordingly.

Example: If help desk trends show frequent identity mismatches or audit findings highlight gaps, increase proofing requirements for affected scenarios or user groups.

Institutions should take a practical, risk-based approach to identity proof that follows the full identity lifecycle. That means setting different assurance levels based on the type of access and knowing when to apply them — like during onboarding, when someone’s access increases, or when credentials need to be recovered. 

It also helps to treat groups (students, employees, affiliates) differently based on their risk level, rather than applying a one-size-fits-all model.

Identity proofing should be built directly into IAM processes and supported by trusted data sources like HR or student systems, with stronger checks when that data isn’t as reliable. Starting small — such as focusing on onboarding first — and then expanding to higher-risk scenarios keeps things manageable. 

Just as important, institutions should avoid unnecessary friction by only stepping up verification when the risk calls for it. Over time, reviewing outcomes and adjusting the approach ensures it remains effective and grounded in real-world needs.

Godgift Iteghete, Sr. IAM Consultant, Moran Technology
godgift.iteghete@morantechnology.com

Question: What was your biggest takeaway from InCommon BaseCAMP 2026?

Response: My biggest takeaway from InCommon BaseCAMP 2026 was how collaborative the higher education IAM community truly is. 

Having worked in several areas of higher education and edtech, I often experienced environments that felt competitive, where organizations were more focused on differentiating themselves than working together. 

BaseCAMP offered a refreshing contrast by bringing together professionals who were genuinely invested in sharing knowledge, discussing challenges, and helping one another succeed.

As this was my first InCommon conference, it was exciting to experience that sense of community firsthand. The conversations extended far beyond the sessions, creating opportunities to exchange ideas, learn from others’ experiences, and even contribute my own perspective. It was clear that everyone shared a common goal of strengthening identity and access management across higher education.

From a Cirrus Identity perspective, BaseCAMP gave me a much deeper understanding of the environments our customers work in and the complex challenges they navigate every day. It reinforced that our role extends beyond implementing technology — we’re helping institutions advance larger IAM initiatives that improve security, access, and the overall user experience. That broader perspective will help me be a stronger implementation partner as I continue supporting our customers.

Traci Hawes, Customer Implementation Lead, Cirrus Identity

Response: My biggest takeaway from InCommon BaseCAMP 2026 was gaining a better understanding of the people and institutions we support every day. 

As someone who is relatively new to both InCommon and the identity and access management space, BaseCAMP provided valuable context around the challenges and priorities facing higher education institutions. While the technical concepts were important, what stood out most to me was seeing how passionate campus IAM professionals are about creating secure, reliable, and accessible experiences for their users.

I also appreciated how welcoming the program was to newcomers. BaseCAMP not only provided a strong foundation in IAM concepts, but also highlighted the many resources available for continued learning. Knowing there is an active community of practitioners willing to share knowledge and support one another makes the IAM journey feel much more approachable.

I left with a greater appreciation for the role IAM plays in higher education and a better understanding of the environments our customers navigate every day. That perspective will help me be a more effective implementation partner as I continue to support institutions in their IAM initiatives.

Kanesha Patrick, Customer Implementation Lead, Cirrus Identity

Question: What strategies have you suggested for managing machine identities and service accounts?

Response: Machine identities and service accounts are often not managed properly due to a phenomenon called shadow IT. 

Most of these identities and accounts exist solely for a single purpose, and it’s very simple for IT administrators to create them manually and use them immediately, bypassing official processes. They are even doing so in good faith — to save the effort of others when they configure everything on their own because surely it won’t bring any risk when they secure it properly. Over time, these accounts can pose a risk, and we should all invest time in managing them properly. 

The described situation is quite common, and even if it doesn’t match your case, you most likely have other reasons for having many machine identities that are not managed properly. 

Our main recommendation is to start building an inventory of such accounts. It might be tedious work, but it’s better to start slowly and eventually cover all or at least most of them, rather than ignore this problem completely. 

The inventory should help you understand the essence of every machine identity, including what its purpose is, who is responsible for it, and what access it has. 

The good thing is that you don’t need any special procedures for this. You can use the same approach you use to manage human identities. Use identity governance and administration (IGA) as the place where you will build the inventory, and use its ability to detect orphaned accounts for discovery, its identity matching to avoid duplicate records and reports, and its reconciliation to help you keep order. Many other standard IGA features, such as notifications and dashboards, might come in handy too. 

In the end, having the inventory will help you understand which machine identities you have and enable you to govern them effectively. Also, having this level of visibility gives you enough information to make strategic decisions about your future plans.

Slavek Licehammer, Head of Engineering, Evolveum
academia@evolveum.com