IT tools should remove work, not add it

Before starting Just Software, I spent many years building and running cloud platforms and operations teams. One pattern kept repeating: the systems that caused the most trouble were rarely the big, visible ones. They were the small supporting servers that someone set up years ago, that “just worked”, until the day they didn’t.

That experience shaped one simple belief, and it’s behind everything we build:

Most insecure IT setups aren’t caused by people not knowing better. They exist because the secure option was too much work.

The secure option loses because it’s harder

Take Wi-Fi. Almost every IT admin knows a shared Wi-Fi password isn’t great. They know certificate-based Wi-Fi is better. Yet most organizations still use the shared password.

That’s not ignorance. It’s arithmetic. The secure option traditionally meant a certificate authority, an NDES server, a connector, a RADIUS server, and the knowledge to keep them all running. The insecure option meant typing a password into a box. When a small IT team has to choose between those two, the shared password wins every time.

The same pattern shows up everywhere:

• Azure changes aren’t tracked, because setting up change tracking is a project of its own.

• Development environments run around the clock, because scheduling them takes effort nobody has time for.

• Certificates are issued by hand, because automating them requires infrastructure.

If you want people to choose the secure option, you have to make it the easy option. Telling them it’s the right thing to do isn’t enough.

“Free” servers aren’t free

Many of the traditional building blocks come “free” with Windows Server: Certificate Services, NDES, Network Policy Server. But a free server role still costs you:

• Patching and upgrades, including the occasional major version migration nobody budgeted for

• Backups and disaster recovery, which are rarely tested until they’re needed

• Certificates that expire. The server’s own, the CA’s, the connector’s, usually on a weekend

• The one person who knows how it works. When they leave, the knowledge often leaves with them

• Attack surface. Every server you run is a server that can be compromised

None of these costs shows up on an invoice, so they’re easy to ignore. But they’re paid every year, in hours and in risk.

Complexity is a security problem

There’s a quieter cost as well. Complex systems get misconfigured, and systems nobody fully understands don’t get changed, even when they should. Workarounds pile up: an exception here, a firewall rule there, a service account with more rights than it needs because that was what made it work.

Over time, the complexity itself becomes the vulnerability. A simpler system, with fewer moving parts and secure defaults, is often more secure than a sophisticated one that nobody dares touch.

How we build

These are the rules we hold ourselves to:

1. No servers for you to run. Our products run as cloud services we operate. There’s nothing for you to install, patch or back up, and nothing to publish to the internet.

2. Secure by default. The default configuration should be the secure one. You shouldn’t need a 40-page guide before you get value, or to harden the product after installing it.

3. Open standards. We build on RADIUS, 802.1X, SCEP and X.509: standards your devices and access points already understand. No proprietary agents on your devices, and no special hardware.

4. Do one thing well, and say no to the rest. Simplicity means saying no. For example, EasyScep delivers certificates through SCEP and deliberately not through PKCS, because with SCEP the private key is generated on the device and never leaves it. Fewer options, but a better default.

5. Show what’s happening. When something fails, you should be able to see why without calling us. That’s why our products include live logs and diagnostics. Often, the answer is right there in a log line.

6. Buy it the way you already buy. Our products are available on Azure Marketplace and billed on your Azure invoice. Some of them also count toward an existing Azure commitment. No new supplier onboarding, no separate procurement process.

The test we use

Whenever we design a feature, we ask one question: does this remove work for the customer, or add it?

If the answer is “it adds work, but it’s powerful”, we usually don’t build it. Or we keep working on it until the answer changes. A tool that adds work will slowly be worked around, and a security tool that gets worked around protects nothing.

IT teams, especially small ones, don’t need more tools. They need fewer problems. That’s what we’re trying to build.

Want more on how to make secure IT simpler? Subscribe to our newsletter.