Security: 2FA and SSO for Windows Applications in 2025

This blog covers the circumstances under which you might choose to enable 2FA, SSO, both or neither to secure access to Windows applications. The discussion centers around how to configure these security measures with GraphOn GO-Global. GO-Global is a Windows application publishing tool that enables secure access to Windows applications from wherever users are, using any device that supports a browser—be it a Surface Pro, Dell XPS, MacBook Air, Samsung Galaxy, or one of many other types. (For more information about GO-Global’s inherent security features, see “Designed with Security in Mind.”)

When you start exploring identity and access management (IAM) best practices, you’re likely to find an overwhelming number of reputable sources offering a wealth of recommendations. But you’ll also find a few common denominators that apply to small- to medium-sized businesses (SMBs), enterprises, and cloud services providers alike, regardless of the assets they’re protecting:

• Users’ digital accounts must be protected with credentials such as passwords. Ideally, policies dictate criteria for strong passwords and underscore the importance of keeping credentials secret and secure.

• Credentials that allow access to applications that expose sensitive information should be verified with some form of multi-factor authentication (MFA), such as two-factor authentication (2FA). 2FA helps confirm that users are (in the flesh) the users their credentials represent.

• Single sign on (SSO) better protects credentials from human foibles (such as forgetting and reusing passwords) and mitigates the perceived inconvenience of 2FA.

Which principles you employ and when depends on several variables. Among other things, you’ll need to consider the information exposed by the applications users have rights to. You’ll also need to consider how users access those applications. Are users in the office or working remotely? Are the applications in an enterprise data center or in the cloud? Will remote users access the applications over the Internet? With or without the encryption afforded by a VPN?

The Internet Doesn’t Know You’re a Dog

Despite increasingly sophisticated cybersecurity measures, the baseline authentication method remains the password, which confirms identity based on something users know. Whether getting on their phones, accessing work email, or logging into business-critical applications, users enter self-invented combinations of letters, numbers, and special characters to do so.

The trouble with passwords is users. They like short passwords because they’re easier to remember, but short passwords are also easier to guess. Knowing this, admins and applications insist that users create longer passwords, which are harder to crack but can be harder to remember. (See, “The New Strong: Easy to Remember, Hard to Crack.”)

When users have dozens of accounts requiring complex passwords, they tend to resort to less-than-secure practices: they write them down or, worse and more common, reuse them. At least 65% of users reuse passwords and 13% use the same password for all accounts and devices.

Not surprisingly, passwords are the source of a notoriously common attack vector: compromised credentials. In fact, according to a recent report by IBM and Ponemon, “compromised credentials” was the most common initial attack vector in 2021, ultimately leading to 20% of all data breaches.

No matter how “secure” passwords are, attackers can expose them. Even if SallyB creates a password that would take a computer 23 duodecillion years to crack, that remains true only if she keeps it secret. (See Figure 1.) But perhaps SallyB unwittingly provides all the answers to her password reset questions in her Facebook account. Or maybe she gets an email and clicks the embedded link, which takes her to a doppelganger site for sign-in, where an attacker captures her credentials.

Based on credentials alone, systems cannot know if “SallyB” is in fact SallyB. The reason sounds silly but is nevertheless true: computers can’t see.

‍

2FA: If Systems Had Vision

Enabling 2FA is like giving your systems vision. 2FA requires two distinct forms of identification to authenticate. The first form is generally something users know (e.g., a password). The second is typically something users have, such as a code sent via text or, for a more secure option, a code generated by an authenticator app installed on a user’s phone.

To thwart 2FA that relies on such codes, attackers would need not just a user’s credentials but also that user’s phone. This additional layer of security is extremely effective. In fact, according to a 2019 Google study, using 2FA with an on-device prompt prevents 100% of automated bot attacks, 99% of bulk phishing attacks, and 90% of targeted attacks.

Not surprisingly, 2FA is widely considered a best practice for securing remote access and is a requirement for any zero-trust architecture.

When to Enable 2FA

Under what circumstances should you enable 2FA? The simple answer is this: enable 2FA for any system that exposes sensitive or privileged information.

Enabling 2FA for every system might not be the best choice. Users can run into situations when 2FA can hinder access—their cell phone signal is sketchy, for example, or their phone has been lost or stolen. Granted, most 2FA systems have workarounds for situations such as these. For example, GO-Global allows you to reset codes from within the Admin Console so that users can gain access to 2FA-enabled hosts even if they lose their phone. Nevertheless, you should weigh the perceived inconvenience of 2FA against what users have rights to access.

For example, consider the common set of applications that you make available to all (e.g., Office 365, time-keeping software, Adobe products). If these applications are running behind your firewall, credentials alone for on-prem users would suffice. Even for remote users, assuming they have rights to only the common set of applications with access to non-sensitive data, credentials alone would arguably suffice. But you must ask yourself, “If ‘SallyB’ isn’t SallyB but an attacker, what’s at risk?”

For applications that potentially expose sensitive data, the slight inconvenience that 2FA might occasionally cause is worth fielding a few complaints. For example, for these types of users accessing these types of applications, you should enable 2FA:

• Developers with access to coding software

• Engineers with access to network sniffers

• IT admins with access to firewall and router configuration software

• Accountants with access to payroll apps

• Sales team members with access to Customer Relationship Management (CRM) systems

• Human resource (HR) personnel with access to HRM software

What if the users listed above are accessing these applications over a VPN? A VPN creates a tunnel of sorts across the Internet, encrypting the information exchanged between users and the systems they access. But a VPN cannot determine whether the entity who entered correct credentials for “SallyB” is SallyB. Therefore, with or without a VPN, if a user’s role allows access to sensitive data, you should enable 2FA to protect it.

{{CTAEMBED_IDENTIFIER}}

Setting Up 2FA in GO-Global

Enabling 2FA on a GO-Global server hosting Windows applications is a simple process. You begin by selecting Host Options from the Tools menu in the Admin Console and clicking the Authentication tab. From that screen, you click, “Require two-factor authentication.” After you click “Okay,” 2FA is enabled. (See Figure 2.)

Each time users connect to a 2FA-enabled GO-Global host, the system first prompts them to enter their username and password via the Sign In dialog. (See Figure 3.) When users click “Sign In” for the first time, the system prompts them to register for 2FA and describes the two steps required to do so.

• Step 1 prompts users to download an authenticator app on their phone. Users can install the app they choose (e.g., Google Authenticator, Authy, Duo Mobile, and LastPass Authenticator).

• Step 2 prompts users to open the app, click “add” or “+,” and then scan the displayed QR code. (See Figure 4.) The scanned QR code ties this user and this phone to GO-Global. (Users only need to scan the QR code once regardless of how many 2FA-enabled GO-Global hosts they access—as long as you enable “roaming profiles” in the Admin Console.)

After receiving the scanned QR code, the GO-Global host displays a dialog prompting users to enter the 6-digit code from the authenticator app and then click “Okay.” The app automatically refreshes these codes every 60 seconds. When a user has entered the correct current code, the GO-Global host opens App Controller, which displays the published Windows applications.

While explaining this process in writing takes a few hundred words, enacting the process live takes only a few seconds.

SSO: The Power of One

Enabling 2FA helps systems ensure that “SallyB” is the person her credentials represent. But 2FA doesn’t help SallyB remember her passwords—and odds are, she’s got a lot of them.

According to OneLogin, an Access Management Solutions Provider, 68% of users switch between ten applications every hour. If users are being thorough about security, that means they’re potentially entering up to ten unique passwords every hour. But most users aren’t thorough, so they repurpose the same password or resort to other less-than-secure options.

The solution is to enable Single Sign On (SSO). SSO is a user authentication tool that allows users to log in to and access multiple applications, websites, data, and workstations using just one centrally managed set of credentials. SSO is considered a best practice in access security. In fact, the U.K. National Cyber Security Centre (NCSC) cites a “single strong source of user identity” as a key principle of zero-trust architecture.

To implement SSO, organizations partner with an identity provider (IdP). IdPs use a protocol, such as OpenID Connect, to establish trust between an organization’s users and SSO-integrated applications. Users log in to the IdP, which then generates a unique access token. The IdP uses this token to allow users access to the integrated applications to which they have rights.

Eliminating the need for users to enter different credentials for every application makes everyone happy. Users are happy because they typically log in only once a day to the IdP. For you, SSO simplifies the process of auditing and managing users. Security teams can define and enforce stricter password requirements. And help desks get fewer calls for password resets.

SSO for Windows Apps

Unfortunately, SSO has historically been available only for web-based applications—not Windows applications. The problem has been that with Windows, users log directly onto the OS with a username and password, after which Winlogon loads the user’s profile. Because the Windows OS requires a username and password, you typically can’t include Windows applications in cloud SSO implementations without a custom Credential Provider.

The SSO solutions for Windows applications that are available, such as Citrix NetScaler Unified Gateway integrated with Citrix Hypervisor, have a reputation for being both expensive and complex.

GO-Global is poised to change that reputation.

Available as an add-on option, GO-Global’s OpenID Connect authentication feature offers SSO with an easy set up at a fraction of the cost of other SSO solutions for Windows apps. GO-Global enables SSO for Windows applications through IdPs who support OpenID Connect, including Okta, OneLogin, Microsoft Active Directory Federated Services, and Microsoft Azure AD Seamless SSO. When configured, GO-Global OpenID Connect enables users who sign into an IdP to access Windows applications on GO-Global hosts from their browsers without having to re-enter their credentials.

Setting Up SSO in GO-Global

To integrate GO-Global hosts with your organization’s IdP, begin by configuring the IdP to recognize and work with GO-Global. The specific setup naturally depends on the particular IdP. For example, for Okta, among other things, you’ll need to specify the protocol (i.e., OpenID Connect), the redirect URL to the GO-Global host, and the degree to which you want to control access to the host. (For example, you could limit access to select groups or enable access for all.)

For the sake of convenience, GraphOn recommends that you copy a few of the IdP settings (for example, Client ID, Client Secret, and Redirect URL) into Notepad so you can paste them later into GO-Global’s Admin Console. (See Figure 5.)

Once you have configured your IdP, you configure the GO-Global host. To do so, go to the GO-Global Admin Console, select Host Options in the Tools menu, and click the Authentication tab. From here, configuring the GO-Global host to use your IdP requires little more than pasting the aforementioned settings in the appropriate fields.

With the GO-Global host integrated with your IdP, users enter their IdP credentials (when prompted) to access the host from their web browser. After entering their credentials and the host URL, users see App Controller, which displays the published Windows applications.

When users are authenticated via OpenID Connect to the IdP, they are authenticated automatically on Windows according to the options you select. For example, if the IdP is integrated with your organization’s Active Directory, you can configure GO-Global to automatically sign users into their user domains.

For better security and ease of access, you should leverage SSO wherever possible. GO-Global just makes it easier (and less expensive) to include Windows applications among your SSO options.

When Might You Want Both 2FA and SSO?

When might you want to implement both 2FA and SSO? The simple (but not always practical) answer is “whenever possible.” The more-practical and always-wise answer is that to protect sensitive information from unauthorized access, you should enable 2FA. When you do, NCSC recommends that you also leverage SSO to mitigate the “friction” that 2FA introduces. 2FA helps systems ensure that the users attempting access are the users their credentials represent, and SSO prevents sloppy password practices that can lead to a breach.

With GO-Global, you have the means to enable both 2FA and SSO for any Windows applications that you publish on GO-Global hosts.

To learn more, request a demo here or download a free 30-day trial.