Managing External Collaborator Access: When Does Someone Need a JHED Identity?

External collaborators often need access to institutional resources without being traditional employees or students.

That creates an identity-management question:

Should the collaborator receive a sponsored institutional identity, or should access be provided through a guest model?

The correct answer depends on what the person actually needs to do.

A department should begin with the required systems and resources rather than automatically assuming that every external person needs the same type of account.

External collaboration is not one category

A person outside the normal employee or student population can have very different relationships with an institution.

Examples may include:

• contractors;
• consultants;
• vendors;
• temporary researchers;
• project collaborators;
• visiting specialists;
• external partners.

These relationships can differ in duration, sensitivity and system requirements.

A short-term collaborator who needs access to a shared project environment may have very different needs from a long-term contractor who requires access to multiple institutional applications.

Start with the required resource

The most useful question is not:

Does this person need a JHED account?

Instead, ask:

What resources does this person actually need?

Create a list of:

• applications;
• collaboration platforms;
• documents;
• communication services;
• restricted systems;
• project resources.

Then determine which identity model is supported by those resources.

This approach reduces unnecessary access.

Sponsored JHED accounts

Johns Hopkins provides a sponsored JHED account model for people who have legitimate institutional business needs but do not receive an identity through an authoritative source such as the normal student or employee systems.

The sponsoring department assumes responsibility for establishing a legitimate reason for the account.

This model may be appropriate when the collaborator requires access that depends on an institutional identity.

Guest access

A guest model can be appropriate when the required collaboration environment supports external identities.

Instead of creating a full institutional account, the collaborator can use an existing external identity to access specifically shared resources.

This model can reduce unnecessary identity creation while still allowing controlled collaboration.

Access should match the business requirement

Consider three hypothetical cases.

Case 1: Short-term project collaboration

A consultant only needs to participate in a shared collaboration workspace.

A guest model may be sufficient if the platform supports it.

Case 2: Institutional system access

A contractor needs to use an application that requires an institutional identity.

A sponsored JHED model may be necessary.

Case 3: Changing requirements

A collaborator initially needs only document collaboration but later requires additional institutional systems.

The original access model may need to be reviewed rather than simply expanding permissions indefinitely.

The danger of over-provisioning

Creating a broad institutional identity simply because a person needs one narrow resource can create unnecessary access-management work.

The department may then need to manage:

• sponsorship;
• licensing;
• role assignment;
• access review;
• eventual deprovisioning.

The broader the identity scope, the more important lifecycle governance becomes.

The danger of under-provisioning

The opposite problem also exists.

Trying to force every external collaborator through a limited guest model can create operational workarounds when the person genuinely requires institutional access.

The goal is not always to provide the least possible access.

The goal is to provide the appropriate access.

A decision framework for departments

Before requesting access, ask:

What is the person’s relationship with the institution?

What systems do they need?

How long is access expected to continue?

Can a guest model provide the required access?

Does the requested application require a sponsored institutional identity?

Who will own the access decision?

Who will confirm when access is no longer needed?

These questions turn account creation into an access-governance decision rather than a simple administrative request.

Lifecycle planning should begin before access is granted

External access often has a defined purpose:

• a contract;
• a project;
• a research collaboration;
• a temporary engagement.

Whenever possible, the access lifecycle should be considered at the beginning.

Administrators should know:

• why access exists;
• who sponsored it;
• what resources are required;
• who can approve changes;
• what event should trigger a review or removal.

An account is easier to govern when its purpose is clear from the start.

Related articles:

• Sponsored JHED Accounts vs. Guest Accounts Explained
• The JHED Account Lifecycle
• JHED Access Governance
• Access Reviews: Why Permissions Need to Be Rechecked