Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayAt this point, almost no one in network engineering questions the importance of TLS and SSH. These protocols are the foundation of modern secure infrastructure for many devices.
But just because a device claims to support secure protocols doesn't mean it's actually configured securely.
In fact, I regularly see well-meaning engineers make critical mistakes when deploying TLS and SSH. These are simple missteps that open the exact vulnerabilities these protocols are supposed to prevent.
Let's take a close look at the 7 most common mistakes I see and how to avoid them with confidence.
It's easy to be lulled into a false sense of security. The datasheet says "TLS 1.2" and "SSH Supported," so everything must be good, right?
Unfortunately, that's just the starting point. What really matters is how these protocols are configured and used.
You can have the right tools - but use them the wrong way - and still leave the front door wide open. Fortunately, every mistake on this list is fixable.
TLS 1.0 and 1.1 are no longer secure. They've been deprecated by most browsers, flagged by government agencies, and excluded from compliance frameworks like NIST.
So why do I still see so many RTUs and routers shipping with these versions?
Some devices default to the lowest supported version for compatibility reasons. This can be risky since it puts your login sessions and configuration data at risk of interception.
As a best practice, deploy devices that only support TLS 1.2 or higher, with older versions disabled out of the box. That will make sure you're protected against known vulnerabilities and ciphers that attackers already know how to exploit.
Let's be blunt: Telnet is obsolete. It sends all data - including your password - in plain text.
This means that anyone with access to the network can sniff those credentials. It's the digital equivalent of leaving your keys in the ignition - on a busy street.
Even worse, I've seen networks where Telnet was left enabled "just in case," or as a fallback method when SSH wasn't set up properly.
You don't want to make the same mistake - ever.
In order to fix this, you should
Finding the right gear eliminates that risk for you before the device even ships.
Shared logins like "admin/admin" might save time, but they're a nightmare for accountability and security.
This credential reuse becomes an issue when:
If you've ever had to "chase down" who made a config change, you know how frustrating that is.
The fix is simple: Use unique login credentials for every technician.
Be sure to also combine that with role-based access control so users only get access to what they need.
Certain devices - like NetGuardian RTUs - allow you to create and manage user accounts with different permission levels right in the web interface. This means no external servers or tools required.
This mistake happens more often than you'd think - especially in rushed deployments.
Your team installs a new device and everyone's focused on testing alarms and getting SNMP connectivity up. Meanwhile, the login is still set to:
This can be incredibly dangerous since default passwords are published online and commonly repeated across many devices. Bots are actively scanning the internet looking for devices using these default credentials.
To avoid, or correct, this mistake:
DPS G6 devices support password policies that meet common compliance requirements.
SNMPv1 and v2c are functionally obsolete in terms of self-contained security. They send all data - including sensitive alarm info - unencrypted. They also rely solely on a shared "community string," which is basically just a weak password.
Yet, I still see critical infrastructure running on v2c because "we already have a significant investment in this equipment"
Here's the danger:
To solve this, use SNMPv3 for all alarm reporting and remote configuration. It supports full encryption, message integrity, and source authentication.
Even better, if you have legacy devices that only support SNMPv1/v2c, use an SNMPv3 Proxy device that wraps those traps in a secure SNMPv3 envelope. That way, you get modern security without ripping out old gear.
Generally, you wouldn't use an expired ID badge to get into a secure facility. However, I've seen teams use expired, mismatched, or self-signed certificates for years - simply because nobody checked.
Failing to validate TLS certificates leaves your system open to:
What you should do is:
It's easy to think, "We're NIST-compliant, so we're covered." But the truth is compliance is just the starting point - not the ultimate goal.
Standards like NIST and FIPS define minimum acceptable practices. They're a good start, but they don't guarantee you're safe.
If you only aim for compliance, you might miss:
Make sure your security plan includes:
Quality devices include logging, user activity tracking, and built-in security features that exceed basic compliance. If you're being audited, the right gear will even help with documentation.
When you step back, these seven mistakes have a single root cause: false confidence. That false confidence leads to several misconceptions, including the belief that:
In secure protocol deployments, confidence without verification is quite dangerous. What sets apart secure teams from vulnerable ones is consistency.
Truly secure systems need a team that follows a playbook. This team also must choose tools that enforce good habits and never assume security is "done."
If you're reading this, you're probably the kind of engineer who wants that level of control - and doesn't want to leave anything to chance. The good news? You don't have to fix all this manually.
At DPS Telecom, we've worked with thousands of engineers over the past 30 years. We've seen what works - and what goes wrong - when securing critical infrastructure.
Our G6 remote monitoring platform was designed with these 7 pitfalls in mind. From day one, our devices will help you:
Want help reviewing your current security posture? Looking to upgrade your RTUs to something built for today's threats?
Give me a call at 559-454-1600 or email sales@dpstele.com.
I'll walk you through best practices, help you avoid the mistakes in this article, and get you a proposal tailored to your network (including mediation devices that avoid expensive "forklift swap-outs")
It's time to secure your network the right way.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 18 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
