myJH Remote Access: When to Use VPN, MyCloud or the Web

Johns Hopkins provides several ways to reach institutional technology from outside a campus or work location. Current IT guidance identifies three broad approaches: ordinary web access, VPN and MyCloud. The correct option depends on the application being used because many Hopkins services are available directly over the internet, while others are restricted to the institutional network.

myJH helps users reach these resources, but myJH itself is neither the VPN nor the remote desktop. Understanding that difference is the key to avoiding unnecessary remote-access troubleshooting.

Start With the Application You Actually Need

The most useful first question is not:

“How do I connect myJH to VPN?”

It is:

“Does the application I need require Hopkins network access?”

Johns Hopkins explicitly says some internal resources require VPN or MyCloud, while other services are available directly from a browser.

For example, current guidance identifies Outlook, Microsoft 365, Canvas, Zoom and Teams as services that can be used remotely through web or application interfaces without first establishing a conventional campus VPN session.

VPN Connects a Device to Restricted Resources

VPN is intended for resources that require access to the Johns Hopkins network.

The University’s current remote-access page directs users to the Technology category in myJH and then to the VPN resource. The documentation also identifies enterprise MFA and an appropriate VPN client as prerequisites.

This gives a VPN connection several possible failure points:

• JHED authentication;
• MFA;
• VPN client configuration;
• network connectivity;
• authorization for the destination resource.

A myJH password reset cannot solve all of them.

MyCloud Solves a Different Remote-Access Problem

Johns Hopkins describes MyCloud as a primary supported solution for securely accessing data and applications remotely. The IT Cloud/Data Storage page says MyCloud and Virtual Desktop can be used to securely access work from anywhere.

Current remote-access guidance provides more detail: MyCloud can give eligible faculty and staff access to hundreds of applications or to a Windows desktop containing applications and documents. Johns Hopkins also identifies it as a route for certain clinical applications such as Epic.

That is materially different from VPN.

VPN vs MyCloud

With VPN, the user’s own computer establishes a secure connection to Johns Hopkins network resources. The applications generally continue to run on the user’s local device.

With MyCloud, the user can work through remotely delivered applications or a virtual Hopkins desktop. Current documentation identifies Citrix-related software and MFA among the prerequisites for that environment.

This distinction explains why one access method may work for a particular Hopkins application while another is recommended for a different one.

MyCloud Is Not Universal

The current Johns Hopkins remote-access page specifically describes MyCloud’s broad virtual-desktop/application access in a faculty/staff context.

Students should therefore not assume that every faculty/staff remote desktop feature applies to their account. myJH serves many Hopkins populations, but the resources available within it are personalized according to the user’s institutional access.

A missing MyCloud resource can therefore reflect eligibility rather than a portal malfunction.

Outlook and Microsoft 365 Usually Do Not Need VPN

Email is a useful comparison.

Current Johns Hopkins guidance says Outlook web access is available through the Messaging category in myJH and may require MFA. Microsoft 365 tools are likewise available through the web and are explicitly described as not requiring VPN.

If your only goal is to read email or work in an eligible browser-based Microsoft 365 service, connecting a full VPN session may add complexity without solving a real requirement.

See /myjh-email-outlook/ for the email-specific workflow.

Canvas, Teams and Zoom Illustrate the Same Principle

Johns Hopkins also identifies Canvas, Teams and Zoom as remotely available without requiring VPN for ordinary access.

These examples make a useful general model:

Web/cloud application → often accessible directly with Hopkins authentication.

Internal network application → may require VPN.

Hosted application or virtual desktop → may be delivered through MyCloud.

The application’s own documentation should always override a generic assumption.

MFA Is a Shared Dependency

VPN, MyCloud and other Hopkins services can depend on multi-factor authentication.

That makes MFA a common failure point across otherwise unrelated technologies. If several services stop at the same authentication stage, it is more plausible that the common identity/MFA layer is failing than that VPN, MyCloud and Outlook all broke simultaneously.

Johns Hopkins currently highlights MFA within its Networks & Connectivity and authentication services.

The separate /myjh-password-mfa/ page should own detailed MFA troubleshooting.

Clinical Applications Add Another Authorization Layer

Johns Hopkins identifies MyCloud as a route for clinical applications such as Epic, but availability of MyCloud does not imply that every Hopkins user can open every clinical system.

There are at least two separate questions:

Can the user technically reach the remote environment?

and

Is the user authorized for the application inside it?

An account can succeed at the first and fail at the second.

This distinction is especially important in healthcare and research environments where application permissions are role-specific.

Local IT Support Matters

The official remote-access guide recommends contacting local IT support when users need help selecting the appropriate remote-access method.

That advice reflects the decentralized nature of Johns Hopkins technology. A researcher, student, clinical employee and administrative staff member may require very different resources even though all of them use myJH.

An independent article can explain VPN and MyCloud generally, but a department’s specific application requirements can make local IT the better authority.

Troubleshoot by Stage

When remote access fails, diagnose the last successful stage.

myJH does not authenticate:
Investigate JHED/password/MFA.

myJH works but the VPN client cannot connect:
Investigate MFA, VPN software and network configuration.

VPN connects but the internal application still fails:
Investigate application availability or authorization.

MyCloud opens but an expected application is missing:
Investigate whether your Hopkins role is provisioned for that application.

Outlook works without VPN:
That can be completely normal under current Hopkins remote-access guidance.

myJH Is the Starting Point, Not the Remote-Access Technology

The useful way to think about the system is:

myJH helps you find the resource.

JHED/MFA verifies your identity.

VPN provides network connectivity when needed.

MyCloud provides remote applications or a virtual desktop where applicable.

The destination application then performs the actual work.

Once those roles are separated, “remote access” stops looking like one giant login problem.