Johns Hopkins provides several ways to reach institutional resources when working or studying away from campus. Current IT guidance separates them into three broad approaches: ordinary web access, VPN, and MyCloud. Which one you need depends on the resource, because not every Johns Hopkins application requires a connection to the institutional network.
myJH helps users reach several of these services, but the portal itself is not the VPN or remote desktop.
Understanding that difference prevents a common mistake: installing remote-access software for a service that was already available directly through a browser.
Start With the Resource, Not the Technology
Before deciding that you “need VPN,” determine what application you are trying to reach.
Johns Hopkins explicitly says that many resources are restricted to its campus network and therefore require VPN or MyCloud, but other major services can be used directly over the web.
That makes the correct question:
What access method does this particular Johns Hopkins resource require?
rather than:
How do I put all myJH traffic through VPN?
Ordinary Web Access
Some Johns Hopkins services are designed to work remotely without creating a full institutional network connection.
Current IT guidance lists examples including:
- Outlook web access;
- Microsoft Office 365;
- Canvas;
- Zoom;
- Microsoft Teams.
Individual services can still require authentication or MFA.
But needing Johns Hopkins credentials is not the same thing as needing VPN.
VPN: Connecting to Network-Restricted Resources
A virtual private network creates a secure connection that allows an off-campus device to reach resources requiring Johns Hopkins network access.
Current Hopkins remote-access guidance directs users to myJH, then the Technology category, to locate the VPN resource. The institution’s instructions also identify enterprise MFA and the appropriate VPN client among the prerequisites.
This means VPN access involves several moving pieces:
- a valid institutional identity;
- successful MFA;
- appropriate VPN software;
- an account authorized for the resource;
- the destination application itself.
Failure at any one of these points can be misreported simply as “myJH VPN doesn’t work.”
What MyCloud Does
Hopkins MyCloud solves a somewhat different problem.
Johns Hopkins IT describes MyCloud as a fully supported solution for remotely accessing applications and data, with virtual-desktop functionality that can provide a Windows environment containing appropriate applications and documents.
The institution’s remote-access guide says MyCloud can provide faculty and staff with access to hundreds of applications or a Windows desktop and can be used for clinical applications such as Epic where applicable.
The important point is that MyCloud is not simply another name for VPN.
VPN vs MyCloud
Both can help an off-campus user reach restricted resources, but they do it differently.
VPN
VPN connects the user’s device to resources available through the Hopkins network.
You continue working largely through software and browsers on your own computer.
MyCloud
MyCloud can provide a hosted application or virtual-desktop environment.
Instead of making the local machine behave as though it were simply on the Hopkins network, the user can work through a remotely delivered Hopkins computing environment.
That difference can affect which option makes sense for a particular application.
MyCloud Has Additional Prerequisites
Current Johns Hopkins documentation identifies MFA and Citrix software as requirements for MyCloud access.
Therefore, if myJH works but MyCloud does not launch, several questions become relevant:
- Is MFA functioning?
- Is the required client installed?
- Is the account eligible for MyCloud?
- Is the application itself available to the user?
- Is local IT directing the user toward a different remote-access method?
A myJH password reset will not solve every one of those scenarios.
MyCloud Availability Is Not Universal
The current remote-access guide describes MyCloud’s Windows desktop and application access in the faculty/staff context.
Students should therefore avoid assuming that a resource visible in an employee remote-work guide must also be provisioned identically to a student account.
myJH spans a very broad Hopkins community, but the applications available after authentication vary.
This is also why the portal’s Recommended Tools are curated according to resources available to each individual user.
Clinical Applications Create Their Own Requirements
Johns Hopkins specifically identifies MyCloud as one method for reaching clinical applications such as Epic.
That does not mean every JHED user automatically receives clinical-system access.
The remote-access technology and the business authorization are different layers.
A person might be technically capable of opening MyCloud while lacking authorization for a particular clinical application.
Conversely, an authorized employee may still have a technical problem with Citrix, MFA or the local device.
Outlook Usually Does Not Require the Same Remote-Access Path
Email is a useful comparison.
Hopkins instructs users to access Outlook’s web client through the Messaging category in myJH and notes that MFA may be required. Microsoft Office 365 is also available remotely through the web without VPN according to current institutional guidance.
So if your only goal is to check email, launching a full VPN session may add unnecessary complexity.
See our myJH email and Outlook guide for that workflow.
Canvas, Teams and Zoom Are Different Again
The current remote-access guide says Canvas can be accessed through the web and does not require VPN. The same guidance treats Zoom and Microsoft Teams as internet-accessible collaboration services rather than network-restricted applications.
That gives a useful pattern:
Cloud/web service → often direct internet access plus authentication.
Internal network resource → may require VPN.
Hosted Hopkins desktop/application environment → may use MyCloud.
This will not determine every case, but it is a much better starting model.
MFA Is a Shared Dependency
VPN, MyCloud and other remote services can rely on Johns Hopkins multi-factor authentication.
That makes MFA a shared failure point.
If several otherwise unrelated services suddenly stop at the same authentication stage, investigate MFA before assuming that VPN, MyCloud and Outlook all broke independently.
This becomes especially relevant as Hopkins transitions away from SMS and voice-call MFA before the end of 2026. Johns Hopkins plans to disable those methods in mid-December 2026.
Why Local IT Still Matters
Johns Hopkins itself recommends contacting local IT support when users need help determining the most appropriate remote-access approach.
That advice matters in a decentralized institution.
Different schools, departments, clinical areas and research environments can have different application needs or security requirements.
An employee working with an internal administrative application should not assume instructions written for a researcher, student or clinician are interchangeable.
Diagnose Remote Access by Stage
A useful troubleshooting sequence looks like this:
myJH Will Not Authenticate
Treat it as a JHED/password/MFA problem first.
myJH Works but VPN Will Not Connect
Investigate the VPN client, MFA and VPN configuration.
VPN Connects but the Application Fails
The issue may be application authorization or the destination system itself.
MyCloud Opens but the Required App Is Missing
Investigate application entitlement rather than resetting myJH.
Outlook Works Without VPN
That can be normal because Outlook web access is not treated like a campus-network-only application in current Hopkins guidance.
One Portal, Several Access Models
myJH is most useful here as a routing layer.
It can point a user toward:
- Outlook;
- VPN;
- MyCloud;
- Microsoft resources;
- other Hopkins applications.
But each destination has its own access model.
Knowing whether you need ordinary web authentication, network access or a virtual desktop is more valuable than treating everything outside campus as a generic VPN problem.