ADAM PULSE Knowledge Base
Cybersecurity · Remote Access · RDP and SSH

Is Remote Desktop or SSH safe to expose to the internet?

By Michael Obraitis, Managing Partner, and Michael Dale, CEO·Published August 12, 2026·Last reviewed August 2026·ADAM Pulse Knowledge Base

The short answer: Remote Desktop Protocol and SSH are legitimate and extremely useful remote administration technologies, but exposing them directly to the public internet can create significant security risk. When remote access is necessary, businesses should reduce public exposure, use strong authentication, enable multifactor authentication where appropriate, keep systems patched, restrict who can connect, monitor authentication activity, and consider secure access architectures such as VPNs or Zero Trust remote access.

The problem is not that remote access is inherently bad.

Modern businesses need remote access.

Employees work from home.

IT administrators manage servers remotely.

Vendors troubleshoot equipment.

Support companies maintain applications.

Network engineers manage firewalls and routers.

The security question is not:

“Should we ever allow remote access?”

The better question is:

> “How do we provide remote access without unnecessarily exposing critical systems to the entire internet?”

That distinction matters.

Because there is an enormous difference between:

An authorized technician can remotely administer this server

and

Anyone on the internet can reach the server login screen and try to authenticate.

Remote access should provide convenience to authorized users.

It should not provide unnecessary opportunity to everyone else.

What Is Remote Access?

Remote access allows a person or system outside the local network to connect to technology inside an organization.

Examples include:

Remote access is essential to modern business operations.

But it creates an important architectural decision.

You are intentionally providing a path from somewhere outside your normal environment to something inside it.

That path needs protection.

Why Is Remote Access a Cybersecurity Concern?

Because remote access changes who can potentially interact with a system.

A server that can only be reached from inside a protected corporate network has one exposure profile.

A server whose login interface is reachable from anywhere on the public internet has another.

Once a remote access service is publicly reachable, automated systems may discover it.

That can lead to:

The attacker does not necessarily need to know your business exists.

They may simply discover the service.

What Is Remote Desktop Protocol?

Remote Desktop Protocol, commonly called RDP, is a Microsoft protocol used to remotely interact with Windows computers.

It allows an authorized user to see and control a remote Windows desktop.

RDP can be extremely useful for:

The technology itself serves a legitimate purpose.

The security problem arises when RDP is poorly protected or unnecessarily exposed.

Is Remote Desktop Safe?

RDP can be used securely when it is properly designed, configured, patched, restricted, authenticated, and monitored.

But simply enabling Remote Desktop and exposing it directly to the public internet is not a strong remote access strategy.

CISA specifically identifies exposed RDP as a concern in ransomware prevention guidance.

CISA advises organizations not to expose services such as Remote Desktop directly to the web unless necessary and appropriately protected.

That recommendation exists for a reason.

Attackers know RDP can provide powerful access.

Why Do Attackers Look for RDP?

Because successful RDP authentication can provide interactive access to a computer.

Instead of exploiting dozens of complicated systems, an attacker with valid credentials may simply log in.

Consider what legitimate administrators can do through Remote Desktop.

They can:

If an attacker gains equivalent access, the same capabilities can become dangerous.

This is why remote access credentials are valuable.

Can Hackers Find RDP Servers Automatically?

Yes.

Publicly reachable services can be discovered through internet scanning.

Attackers do not necessarily need to manually search for:

“Businesses using Remote Desktop.”

Automated tools can identify systems responding on network services associated with remote access.

Once something is discovered, additional automation may begin testing it.

This connects directly to earlier articles in this series.

Attackers automate discovery.

A publicly exposed remote access service creates something for that automation to discover.

What Port Does RDP Use?

RDP commonly uses TCP port 3389.

However, this needs an important clarification.

The security issue is not simply the number 3389.

Changing the RDP port to another number may reduce some low quality automated noise.

But it does not transform an exposed remote access service into a secure architecture.

Security should not depend on:

“Hopefully the attacker does not know which port we changed it to.”

Modern scanning tools can identify services on many different ports.

Changing a port is not a substitute for proper access controls.

Is Changing the RDP Port Enough?

No.

This is commonly called security through obscurity.

Obscurity can sometimes reduce noise.

It should not serve as the primary security control.

Imagine moving the front door of your building around the corner.

A burglar may not see it immediately.

But if the door remains unlocked, moving it did not solve the fundamental problem.

The stronger controls are things such as:

The objective is not to hide the door.

The objective is to secure it.

What Is SSH?

SSH stands for Secure Shell.

It is a widely used protocol for securely connecting to and administering computers and network devices.

SSH is particularly common in:

Administrators frequently use SSH to execute commands remotely.

Like RDP, SSH is an essential administrative technology.

And like RDP, it deserves careful protection.

Is SSH Safe?

SSH can provide very strong remote access security when configured appropriately.

But an SSH service exposed to the public internet may still receive automated authentication attempts and scanning.

Security depends on more than the encryption protocol.

Businesses should consider:

A secure protocol can still be deployed insecurely.

Is SSH Better Than RDP?

That comparison is not particularly useful because the protocols solve different operational needs.

SSH commonly provides command line administration.

RDP provides graphical Windows desktop access.

Both can be appropriate.

Both can also be misconfigured.

The more important question is:

How is remote access being protected?

What Happens When SSH Is Exposed to the Internet?

An internet accessible SSH service may receive automated activity looking for:

Attackers may attempt usernames such as:

root

admin

administrator

or other predictable accounts.

Automation means those attempts can occur continuously.

That does not mean every SSH server connected to the internet will be compromised.

It means the server should be designed with the assumption that someone may eventually try.

Why Is Root Login Important?

On many Unix and Linux systems, the root account has extensive privileges.

If an attacker successfully authenticates directly as root, they may immediately gain powerful control.

A stronger administrative model may use individual user accounts with controlled privilege elevation.

This can improve:

Instead of:

Everyone logs in as root

the organization can better determine:

Who logged in?

What privileges did they use?

What did they do?

Accountability matters.

What Is SSH Key Authentication?

SSH can use cryptographic key pairs rather than relying solely on passwords.

One part of the key remains private.

Another is installed on the systems the authorized user needs to access.

This can provide strong authentication when keys are properly generated, stored, protected, rotated, and revoked.

But SSH keys create their own management responsibilities.

Businesses should know:

Who owns this key?

Where is the private key stored?

Which systems accept it?

Does the employee still work here?

Was the key copied somewhere else?

Can we revoke it?

When was it created?

Keys are credentials.

They require lifecycle management just like passwords.

Can SSH Keys Be Stolen?

Yes.

Cryptographic keys are powerful credentials.

If a private SSH key is improperly stored and an attacker obtains it, they may be able to authenticate wherever that key is trusted.

This is why private keys should be protected carefully.

Organizations should avoid creating unmanaged keys that remain trusted indefinitely.

A forgotten key can become similar to a forgotten password.

What Is a VPN?

VPN stands for Virtual Private Network.

A VPN can provide an encrypted connection between an authorized remote user or location and the organization's network.

Instead of exposing every internal service individually, an organization can require users to authenticate to the secure remote access environment first.

Then authorized users can access appropriate internal resources.

A simplified model looks like:

Internet

↓

Secure VPN authentication

↓

Authorized network access

↓

RDP, SSH, or other internal resources

instead of:

Entire internet

↓

Direct RDP or SSH login

The FTC recommends secure remote connections and specifically tells businesses to consider VPNs for employees and vendors connecting remotely.

Does a VPN Automatically Make Remote Access Secure?

No.

A VPN is another security control.

It also requires protection.

VPN appliances can contain vulnerabilities.

VPN accounts can be compromised.

Passwords can be reused.

MFA can be absent.

Old accounts can remain enabled.

Administrators can misconfigure access.

Attackers have targeted vulnerable VPN infrastructure in real incidents.

The correct lesson is not:

“VPN equals secure.”

It is:

“A properly designed and maintained VPN can provide a safer remote access architecture.”

Should VPN Access Use MFA?

Yes, particularly when it provides access to sensitive business resources.

The Federal Trade Commission recommends multifactor authentication for sensitive remote access.

CISA also strongly encourages MFA for remote and privileged access.

The reason is simple.

Without MFA:

Password compromised

↓

VPN access may be compromised

With MFA:

Password compromised

↓

Additional authentication required

That extra layer can make stolen credentials significantly less useful.

What Is Zero Trust Remote Access?

Zero Trust is a security approach based on the idea that access should not automatically be trusted based solely on where the user or device is located.

Instead, access decisions can evaluate factors such as:

A Zero Trust remote access gateway may allow users to access specific approved resources without providing broad network access.

CISA's own countermeasure guidance identifies a zero-trust remote access gateway as one option when RDP access is required. The relevant entries are Disable Remote Desktop Protocol (RDP) (CM0025) and Restrict Remote Desktop Protocol (RDP) (CM0042) in CISA's Eviction Strategies Tool, released 30 July 2025: if RDP is needed, it "should be made accessible to users via a secure virtual private network (VPN) connection after authenticating via multi-factor authentication (MFA) or through a zero-trust remote access gateway."

VPN vs. Zero Trust Remote Access

This is becoming an increasingly common question.

A traditional VPN may connect a user into a broader network environment.

A Zero Trust approach may provide narrower access to particular applications or resources after verification.

Neither term automatically guarantees security.

Architecture matters.

Configuration matters.

Identity matters.

Device posture matters.

Monitoring matters.

Businesses should choose based on their environment rather than adopting technology simply because it carries a fashionable label.

What Is a Remote Desktop Gateway?

A Remote Desktop Gateway can provide a controlled intermediary between remote users and internal RDP resources.

Instead of exposing individual computers directly to the public internet, authorized users connect through the gateway.

That gateway can become a central place for:

CISA's remote access guidance specifically points organizations toward secured access architectures when RDP must remain available.

What Is a Jump Box?

A jump box, sometimes called a jump server, is a controlled system administrators connect to before accessing additional protected systems.

The concept is similar to entering a secure building through one controlled checkpoint.

Instead of allowing administrators to connect from anywhere directly to every server:

Administrator

↓

Secure administrative gateway

↓

Authorized internal systems

This provides another opportunity for:

CISA recommends secure intermediaries for remote access. Its joint ransomware advisories carry the mitigation "Require VPNs or Jump Hosts for remote access," and its countermeasure guidance describes using a jump box or jump server between an administrative workstation and a compromised environment.

Should RDP Ever Be Directly Accessible From the Internet?

Direct internet exposure should generally be avoided when safer architectures are available.

CISA's StopRansomware guidance is particularly clear:

Organizations should not expose services such as RDP directly to the web.

If a legitimate business requirement makes exposure necessary, compensating security controls should be implemented.

That does not mean:

Nobody anywhere should ever use RDP.

It means:

Do not confuse needing remote desktop functionality with needing public RDP exposure.

Those are different requirements.

What Does “Internet Exposed” Mean?

A service is internet exposed when systems on the public internet can directly communicate with it.

Imagine two environments.

Environment A

The employee must first connect through a secure access gateway.

Only then can they access the server.

Environment B

Anybody on the public internet can reach the server's RDP login interface.

In both cases, authorized employees may ultimately use Remote Desktop.

But the attack surface is very different.

How Can I Find Out if RDP Is Exposed?

Businesses should maintain an inventory of internet facing services.

That can involve:

Do not assume:

“We do not intentionally expose RDP, therefore we don't.”

Configuration changes accumulate.

Temporary rules become permanent.

Cloud systems are created.

Vendors make changes.

Old servers remain online.

External validation can reveal differences between:

what you think is exposed

and

what is actually exposed.

Why Firewall Rules Matter

Remote access services frequently become exposed because a firewall permits the traffic.

A rule might originally be created because:

A vendor needed emergency access.

An administrator needed to work from home.

A temporary project required it.

A test server was deployed.

Then the project ends.

The rule remains.

That creates an important cybersecurity housekeeping principle:

> Temporary access should have a defined end.

Firewall rules should be reviewed.

Vendor accounts should be reviewed.

Remote access should be reviewed.

Can a Firewall Protect RDP?

Yes.

A firewall can limit which systems are allowed to reach RDP.

Instead of:

Anyone on the internet

the firewall might restrict access to:

Approved networks

or place the service behind another controlled remote access method.

Firewall controls can significantly reduce exposure.

But authentication remains important.

A firewall and MFA solve different parts of the problem.

What Is IP Allowlisting?

IP allowlisting restricts access to approved source addresses or networks.

For example, if a management interface only needs to be accessed from one corporate network, the firewall can permit that source and reject others.

This dramatically reduces who can attempt authentication.

But allowlisting has limitations.

Remote employees may have changing addresses.

Legitimate users may travel.

Cloud environments may be dynamic.

An allowed network can itself become compromised.

So allowlisting is useful.

It should not automatically replace MFA and other controls.

Is Geoblocking Enough?

No.

Geographic filtering can sometimes reduce unnecessary traffic.

For example, if an organization has no business reason for remote administrative access from certain regions, geographic restrictions may reduce exposure.

But attackers can use:

An attacker can appear to originate from your own country.

Geography can provide context.

It does not prove trust.

Why MFA Is So Important for Remote Access

Remote access often provides powerful capabilities.

That makes passwords particularly valuable.

A password can be:

MFA adds another barrier.

This is particularly important for:

Remote access should not rely casually on password only authentication.

What Is Phishing Resistant MFA?

Some MFA methods provide stronger protection against phishing than others.

Phishing resistant authentication makes it more difficult for attackers to trick users into providing reusable authentication information.

Passkeys and appropriately implemented security keys are examples of technologies designed around stronger authentication concepts.

For highly privileged remote administration, organizations should evaluate stronger authentication methods where supported.

Why Administrative Accounts Need Extra Protection

An administrator account may be able to:

That makes administrative remote access particularly sensitive.

An ordinary user account and a domain administrator should not necessarily receive identical security treatment.

Higher privilege should mean stronger protection.

Should Administrators Use Separate Accounts?

Often, yes.

A person may have:

A normal user account

for email and daily work

and

A separate administrative account

for privileged technical tasks.

Why separate them?

If the everyday account is compromised through phishing or normal internet activity, the attacker does not automatically receive the user's highest privileges.

This applies the principle of least privilege.

What Is Least Privilege?

Least privilege means providing only the access necessary to perform a task.

An IT vendor supporting one application may not need:

full network administrator access.

An employee working from home may not need:

access to every server.

A camera vendor may not need:

access to accounting systems.

Remote access should answer:

Who needs access?

To what?

For how long?

From where?

With what privileges?

That is considerably stronger than:

“Give them VPN access.”

Why Vendor Remote Access Is Especially Important

Vendors frequently need connectivity into customer environments.

Examples include:

Vendor access creates a trust relationship.

Businesses should know:

Which vendors can remotely connect?

Which systems can they reach?

Do they use individual accounts?

Is MFA required?

Is access permanent?

Is activity logged?

What happens when the contract ends?

A former vendor should not still have access simply because nobody removed the account.

Should Vendor Access Be Always On?

Not necessarily.

Some environments may benefit from time limited or just in time access.

Instead of:

Vendor can connect forever

the model becomes:

Vendor access is enabled when authorized and needed.

The appropriate architecture depends on operational requirements.

But the underlying principle is valuable:

Persistent access should require a persistent business reason.

Why Endpoint Security Matters for Remote Access

Even a perfectly secured VPN can connect an infected laptop to the business environment.

Imagine:

Secure VPN

plus

Compromised employee computer.

The encryption worked.

Authentication worked.

But the endpoint itself may already be compromised.

This is why the FTC emphasizes that devices connecting remotely should meet appropriate security requirements.

Remote access security includes the device at the other end.

Should Personal Computers Connect to the Business Network?

Businesses should establish clear policies regarding personally owned devices.

If personal devices are permitted, organizations should consider:

Convenience should not eliminate minimum security standards.

The FTC specifically recommends verifying that remotely connecting devices meet the organization's security requirements.

What About Public WiFi?

Remote employees may connect from:

Public networks should be treated carefully.

The FTC recommends secure remote connections and VPN use when employees connect from public WiFi.

But modern remote access security should also include:

The coffee shop network is only one part of the risk.

Can RDP Be Used in Ransomware Attacks?

Yes.

CISA has repeatedly documented threat actors using Remote Desktop and other remote access services during ransomware incidents.

In some cases, attackers use compromised credentials to gain initial access.

In others, RDP may be used after initial compromise to move between systems.

This is why RDP deserves particular attention.

A legitimate administrative capability can become an attacker capability if credentials or systems are compromised.

What Is Lateral Movement?

Lateral movement occurs when an attacker who has gained access to one system attempts to move to additional systems.

Imagine someone enters one office in a building.

They begin testing doors:

Accounting

Server room

Management

Backups

HR

Remote access tools such as RDP can potentially help attackers move between Windows systems when credentials and network access permit it.

CISA specifically identifies adversary use of RDP as a lateral movement technique.

This is why segmentation and least privilege matter.

Why Network Segmentation Helps Remote Access Security

Imagine a remote vendor account becomes compromised.

If that account can access:

Every location

Every server

Every VLAN

Every application

the impact could be enormous.

Now imagine the account can reach only:

One application server required for support.

The account is still compromised.

But the possible damage is reduced.

That is containment.

Remote access should be designed around required access rather than maximum convenience.

Can Remote Access Software Be Abused Too?

Yes.

The security discussion should not be limited to RDP and SSH.

Businesses frequently use legitimate remote support technologies.

Examples can include:

These tools can be extremely valuable.

But any technology capable of remotely controlling computers deserves strong administrative protection.

Attackers have abused legitimate remote management technologies in real incidents.

The important question is:

Who is authorized to control our systems remotely?

Do We Know Every Remote Access Tool Installed?

This is a surprisingly powerful question.

An organization may officially use one remote support platform.

Meanwhile:

A vendor installed another.

An employee installed a personal remote desktop tool.

A consultant installed a temporary agent.

A software provider installed its own support service.

Suddenly the business has five remote access pathways.

Nobody has a complete inventory.

This is a form of attack surface growth.

Businesses should inventory remote management technologies.

Shadow Remote Access

You could think of undocumented remote control software as shadow remote access.

Ask:

Which applications can remotely control computers?

Who installed them?

Who owns the accounts?

Is MFA enabled?

Are they still needed?

Can external parties connect unattended?

Are sessions logged?

Remote access should be deliberate.

Not discovered by accident.

Why Logging Remote Access Matters

Businesses should be able to answer:

Who connected?

When?

From where?

To what system?

Was authentication successful?

What account was used?

Was the activity expected?

These logs become particularly useful during investigations.

Without remote access records, an organization may know:

“Someone changed the server.”

With useful logging, it may be able to determine:

which account connected and when.

What Should Remote Access Monitoring Look For?

Useful indicators can include:

Again, individual events require context.

A technician working at 2 AM may be legitimate.

An unknown administrator connecting at 2 AM may not be.

Should RDP Logs Be Monitored?

Yes, where RDP is used.

CISA specifically recommends monitoring RDP related login activity and examining patterns that may indicate suspicious use.

The important question is not only:

“Is RDP enabled?”

It is:

“Would we know if someone used it unexpectedly?”

This takes us from configuration into detection.

What Should Happen After a Suspicious Remote Login?

The organization should follow its incident response process.

Initial questions may include:

Who owns the account?

Was the user actually connecting?

Was MFA used?

Where did the connection originate?

What system was accessed?

What happened during the session?

Were additional systems accessed?

Did credentials change?

Were new accounts created?

Were security controls modified?

Does the account need to be disabled?

Does the system need to be isolated?

The successful login is only the beginning of the investigation.

Why a Successful Login Can Be More Important Than Thousands of Failures

Imagine:

10,000 rejected RDP login attempts.

That sounds frightening.

Now compare:

15 failed attempts

followed by:

SUCCESS.

Which deserves greater attention?

Probably the second.

Cybersecurity should not focus exclusively on dramatic numbers.

The outcome matters.

This is why useful monitoring asks:

Did anything succeed?

What Should Businesses Do to Secure Remote Access?

A strong remote access strategy should consider multiple layers.

1. Inventory Remote Access

Know every way an external person or device can connect.

2. Eliminate Unnecessary Exposure

Disable remote services that are not required.

3. Avoid Direct RDP Exposure

Use more controlled remote access architectures where possible.

4. Use MFA

Particularly for remote and privileged access.

5. Secure SSH

Use appropriate authentication methods, restrict access, and manage keys carefully.

6. Use VPN or Zero Trust Access Where Appropriate

Create controlled access pathways.

7. Patch Remote Access Infrastructure

Prioritize internet facing systems.

8. Restrict Administrative Access

Not every user needs remote administration.

9. Review Vendor Access

Remove unnecessary and former vendor accounts.

10. Monitor Authentication

Look for suspicious failure and success patterns.

11. Monitor Remote Sessions

Understand when privileged access occurs.

12. Segment Networks

Limit what remotely authenticated users can reach.

13. Secure Endpoints

Require remote devices to meet security standards.

14. Document Changes

Remote access rules should have ownership and purpose.

15. Have an Incident Response Plan

Know what happens when suspicious remote access is detected.

Remote Access Should Have an Owner

Every remote access path should have someone responsible for it.

Ask:

Who requested it?

Who approved it?

Who maintains it?

Who monitors it?

When should it be reviewed?

When does it expire?

Without ownership, temporary remote access tends to become permanent remote access.

Remote Access Should Have a Business Purpose

A firewall rule should not exist because:

“Nobody knows what it does, so we are afraid to remove it.”

A remote account should not exist because:

“Maybe somebody still uses it.”

An SSH key should not remain trusted because:

“It has always been there.”

Every remote pathway should have a documented business reason.

If nobody can explain why access exists, that itself is valuable information.

Remote Access Is Really an Attack Surface Management Problem

At first glance, this seems like an RDP article.

Look deeper.

The real question is:

What can someone outside our organization reach?

That includes:

This is attack surface management.

You cannot secure remote access effectively until you know all the remote access that exists.

Where USA Telecom and ADAM Fit

Remote access is a good example of why operational visibility matters.

USA Telecom and ADAM are not intended to replace:

Those technologies serve specialized security purposes.

But distributed businesses also need visibility into the infrastructure supporting remote connectivity.

Questions may include:

Is the location online?

Is the firewall reachable?

Is the VPN tunnel operating?

Did connectivity change?

Did the internet circuit fail?

Did a remote site's backup circuit activate?

Is an important service unexpectedly unavailable?

Did something change that requires investigation?

The goal is to shorten the distance between:

Something changed

and

someone knows enough to investigate.

Why Remote Access Monitoring Matters Across Multiple Locations

Imagine a company with:

75 locations

Each may have:

Now add:

Remote connectivity becomes an ecosystem.

Manual awareness becomes increasingly difficult.

Standardization and monitoring matter.

A Remote Access Standard Can Reduce Risk

Multi location businesses should consider establishing a consistent standard.

For example:

No direct public RDP unless formally approved.

MFA required for remote administrative access.

Remote access accounts must belong to identifiable individuals.

Vendor access must have documented ownership.

Remote management platforms must be inventoried.

Unsupported remote access technology must be replaced.

Logs must be retained appropriately.

Access must be reviewed when employees or vendors leave.

Consistency reduces forgotten exceptions.

The Question IT Teams Should Ask Before Opening a Port

Someone requests:

“Please open this port so I can connect remotely.”

Instead of immediately making the change, ask:

What are you trying to accomplish?

That question can completely change the solution.

The requester may think:

“I need port 3389 open.”

What they actually need is:

“I need secure remote access to this application.”

Those are not the same requirement.

One describes a technical mechanism.

The other describes the business outcome.

Good security architecture begins with the outcome.

20 Questions Every Business Should Ask About Remote Access

1. What remote access technologies do we currently use?

2. Is RDP exposed anywhere on the public internet?

3. Is SSH publicly reachable anywhere?

4. Why does each exposed service need to be exposed?

5. Are remote users required to use MFA?

6. Are administrators required to use MFA?

7. Who has VPN access?

8. Which vendors have remote access?

9. Are vendor accounts shared?

10. Are former vendor accounts disabled?

11. Are former employee accounts disabled?

12. Are SSH keys inventoried?

13. Are remote access systems patched?

14. Are remote access logs retained?

15. Can we detect repeated authentication failures?

16. Can we identify unexpected successful logins?

17. Are administrative systems segmented?

18. Do remote devices have to meet security requirements?

19. Is temporary remote access actually removed when the work ends?

20. Who investigates suspicious remote access activity?

If several answers are:

“We are not sure,”

that does not automatically mean a breach exists.

But it identifies an area worth reviewing.

The Better Question Is Not “Can I Remote Into It?”

Modern technology makes remote access incredibly easy.

The more important questions are:

Should I be able to reach it directly from the internet?

Who else can reach the login?

Is MFA required?

Could a VPN or secure gateway reduce exposure?

What privileges will the account receive?

Is the endpoint secure?

Is access monitored?

Would we know if someone else logged in?

Does the vendor still need access?

Can the connection be removed when it is no longer required?

That moves remote access from convenience into security architecture.

Key Takeaway

RDP and SSH are not inherently bad technologies.

They are powerful tools.

And powerful tools deserve strong controls.

The mistake is not:

Using remote access.

The mistake is:

Providing more remote access than the business actually needs.

Businesses should:

Know every remote access pathway.

Avoid unnecessary public exposure.

Use MFA.

Protect privileged accounts.

Use VPN or Zero Trust access where appropriate.

Patch remote access infrastructure.

Manage SSH keys.

Review vendor access.

Secure remote endpoints.

Monitor authentication.

Investigate suspicious successes.

Remove access when it is no longer required.

And remember:

> Needing remote access does not automatically mean needing public access.

The business requirement might be:

“Our technician needs to remotely manage this server.”

The security requirement should be:

“Only the technician should have a practical way to reach it.”

That is a much stronger remote access strategy.

Frequently asked questions

Is Remote Desktop safe to expose to the internet?

Direct exposure of RDP to the public internet should generally be avoided when safer alternatives are available. CISA specifically recommends against exposing RDP directly to the web and recommends additional protections when remote desktop access is required.

Can hackers find exposed RDP servers?

Yes. Publicly reachable services can be discovered through automated internet scanning.

Why do hackers attack RDP?

RDP can provide interactive access to Windows computers. Attackers may use stolen credentials, password attacks, vulnerabilities, or compromised accounts to obtain access.

What port does RDP use?

RDP commonly uses TCP port 3389.

Does changing the RDP port make it secure?

No. Changing the port may reduce some automated noise but does not replace secure access controls, MFA, patching, monitoring, or appropriate architecture.

Should RDP be behind a VPN?

A secure VPN is one architecture that can restrict direct RDP exposure. CISA's RDP countermeasure entries (CM0025 and CM0042) recommend a secure VPN connection with multifactor authentication, or a zero-trust remote access gateway, when RDP is required.

What is an RDP Gateway?

An RDP Gateway provides a controlled intermediary through which authorized users can reach Remote Desktop resources instead of directly exposing individual systems.

What is SSH?

SSH is a secure remote administration protocol commonly used for Linux, Unix, cloud, server, and network infrastructure management.

Is SSH safe to expose to the internet?

SSH can be securely configured, but internet exposure increases opportunities for scanning and authentication attempts. Access should be restricted where possible and protected with strong authentication, current software, and monitoring.

Can SSH be brute forced?

Yes. Publicly accessible SSH services can receive automated password and username attempts.

Should SSH use passwords?

Many organizations use cryptographic key authentication and other controls instead of relying solely on passwords. The appropriate configuration depends on the environment.

Can SSH keys be compromised?

Yes. Private SSH keys are sensitive credentials and must be securely stored, managed, and revoked when no longer required.

What is a VPN?

A Virtual Private Network provides a protected connection between a remote user or location and a network.

Is a VPN enough to secure remote access?

No. VPNs also require secure configuration, patching, MFA, account management, endpoint security, and monitoring.

Should VPN accounts use MFA?

Yes, particularly when VPN connectivity provides access to sensitive or internal business resources.

What is Zero Trust remote access?

Zero Trust remote access uses identity and contextual controls to determine access to specific resources rather than automatically trusting a connection based solely on network location.

Is Zero Trust better than a VPN?

The technologies can support different architectures. The right choice depends on business requirements, applications, devices, identity systems, and security needs.

Can ransomware enter through RDP?

RDP has been used by ransomware actors for initial access and movement within compromised networks. CISA specifically includes exposed RDP among ransomware risks organizations should address.

Should remote vendors use MFA?

Remote vendor access should be strongly authenticated and appropriately restricted. MFA is an important control for remote access.

Should vendors have permanent remote access?

Access should reflect business need. Organizations should periodically review vendor access and remove accounts and privileges that are no longer required.

Should firewall administration be accessible publicly?

Administrative interfaces should not be exposed more broadly than necessary. Remote administration should use strongly controlled access methods.

How do I know if someone logged in through RDP?

Windows authentication and RDP related logs can provide information about remote sessions. Organizations using RDP should retain and monitor appropriate logs.

How can I tell if remote access is being attacked?

Indicators can include repeated failed logins, unusual successful logins, unexpected geographic sources, unfamiliar accounts, MFA anomalies, and suspicious activity after remote authentication.

Should small businesses use remote access?

Remote access can be necessary and valuable. The goal is not to eliminate it but to implement it through secure, controlled, monitored methods.

Sources

Editorial note

Cybersecurity risk and the controls appropriate to it vary by organization. Evaluate these recommendations against your own technology environment, business requirements, regulatory obligations, threat profile and risk tolerance.

Talk to us about your network security

USA Telecom Consulting LLC is a Service-Disabled Veteran-Owned Small Business running a 24/7 NOC. We monitor networks, circuits and firewalls for regulated and defense-supply-chain organizations.

Related articles

How do I know if someone is hacking my network? · Why would hackers target my small business? · How do hackers find vulnerable computers? · Does a firewall stop hackers? · What is a botnet and how does it work? · What happens after a hacker gets into your server? · What is malware, and how do you know if a file is malicious? · Is it the ISP or the firewall?

← More from the ADAM Pulse Knowledge Base

Prepared by ADAM Pulse (USA Telecom Consulting LLC) — managed AI governance, network, and NOC services. Support: (888) 989-4872 · support@adampulse.us