Why 1,200 Users Pushed Me from IT Support into Security

When people ask how I got into cybersecurity, they usually expect a story about a hacking competition or a late-night breakthrough with a piece of code. My answer is less dramatic. I got into security because I spent two years keeping 1,200 people working.

From 2022 to 2023 I was an IT Support Specialist at MAS Active Linea Intimo, a large apparel manufacturing plant in Sri Lanka. Before that, I worked as a Network Support Engineer at Exetel, an internet service provider, where my job was to figure out why customers couldn't connect and to get them back online. Neither role had "security" in the title. Both of them pushed me toward it.

This is the first article in a series I'm writing about networks, security and the practical side of IT. I want to start with the why, because I think the path from the help desk to security is one of the most underrated routes into this field.

The plant floor teaches you fast

A manufacturing site is not a quiet office. Production lines depend on computers, label printers, scanners, shared drives and a network that has to stay up through every shift. When something breaks, it doesn't just inconvenience one person. It can hold up an entire line.

Supporting a site that size meant I was constantly switching between very different problems. A workstation that wouldn't boot. A printer that had dropped off the network. A new hire who needed an account, a machine and a quick walkthrough before their first shift. A hardware fault that needed a vendor repair. A network upgrade project that had to happen without stopping production.

You learn three things quickly in that environment. First, you can't fix everything at once, so you learn to prioritize by urgency and business impact. Second, you learn that documentation is the only thing standing between you and solving the same problem twice. Third, and most importantly, you learn that almost every technical problem is also a people problem.

What support taught me about security

At the time, I didn't think of my work as security work. Looking back, it was full of it.

I saw how people really use technology. Security policies are written for the way people should work. Help desk staff see the way people actually work: the shared password taped under a keyboard, the USB stick passed between shifts, the "quick favour" of logging a colleague in. None of this comes from bad intentions. It comes from people trying to get their job done. Understanding that is the starting point of good security, because a control that fights the way people work will be worked around.

I learned that you can't protect what you don't know you have. Part of my role was managing inventory: equipment, spare parts and acquisitions. Asset management sounds administrative, but it is one of the foundations of security. Every unmanaged laptop, forgotten switch or unpatched machine in a corner is a potential entry point. Keeping an accurate inventory was security work, even though nobody called it that.

I learned to read patterns. When you handle tickets every day, you start to notice when something is off. Several users reporting the same strange behaviour. A machine that keeps slowing down at the same time. Network performance that dips in a way that doesn't match normal load. Monitoring the network at MAS and at Exetel trained me to ask "why is this different?", and that question sits at the heart of detection.

I learned that onboarding is where access begins. Every new user I set up was a decision about what they could reach. Get that right at the start and life is simpler. Get it wrong, and permissions pile up over the years until nobody knows who can access what.

I learned that third parties are part of your attack surface. Coordinating repairs with vendors and service providers meant equipment regularly left the building and came back, and outside technicians sometimes needed access to systems. Every one of those hand-offs raises security questions. What data is on that drive? Who is logging in remotely, and for how long? Is the device that came back the same one that left? Supply chain risk is a major topic in security today, and I first met it on a loading dock with a repair ticket in my hand.

I learned to explain technical risk in plain language. Users don't care about protocols. They care about whether they can finish their work. Explaining why a password needed to change, or why a personal USB drive couldn't be plugged in, taught me to frame security in terms of what people value. That skill matters even more in security, where you often need managers to approve changes they don't fully understand.

The moment the switch made sense

There wasn't a single dramatic incident that changed my mind. It was a slow realization that the problems I found most interesting weren't "this is broken" but "why did this happen, and how do we stop it from happening again?"

The more tickets I closed, the more I noticed that many problems started with something ordinary: an outdated system, a weak password, an unexpected device on the network, a link someone shouldn't have clicked. Security incidents rarely begin with something exotic. They begin with the everyday gaps that support teams see constantly.

I also realized that support staff are often the first to notice something is wrong. They take the call when a user says, "My computer is acting strange." Whether that call gets treated as a nuisance or as a possible early warning can make a real difference to an organization. I wanted to be the person who could tell the difference.

Building the foundation

I had already started down this road academically. I earned my Bachelor of Engineering in Computer Network and Security from Staffordshire University in 2021. My final-year project was an Android forensics tool called Forensic Raptor, built in Python, which images a device over ADB and analyzes it for e-commerce app data while verifying evidence integrity with SHA-512 hashes. I'll write about that project in detail later in this series.

I also earned the Certified Ethical Hacker (CEH) credential, which gave me a structured way to think like an attacker: how they gather information, how they find weaknesses and how they move through a network.

Then I moved to Toronto and went back to school. At Seneca Polytechnic I completed a postgraduate program in IT Project Management in 2024, and a second in Cybersecurity and Threat Management in 2025. The project management program taught me how to plan, communicate and deliver technical work. The cybersecurity program connected my hands-on experience to the frameworks, tools and threat models used across the industry.

Outside the classroom, I built a home lab: an Ubuntu server running services in Docker, including Pi-hole for network-wide DNS filtering and a WireGuard VPN for secure remote access. It's where I practise patching, hardening and breaking things on purpose so I understand how to fix them.

What I bring to security now

I don't see my support background as something I moved away from. I see it as an advantage I carry with me.

• I understand end users. Security that ignores the people using the systems doesn't work. I've sat beside users when their system failed, and I know how to explain risk without jargon.
• I know how infrastructure behaves in real life. Networks, endpoints, printers and vendor systems all have quirks that don't appear in textbooks.
• I'm comfortable with triage. Prioritizing by urgency and impact is exactly what incident response asks of you.
• I value documentation. Clear records make investigations faster and recovery smoother.
• I take ownership. On a help desk, a ticket is yours until it's resolved. I bring that same mindset to security work.

Advice for anyone on a help desk thinking about security

If you're in IT support today and you're curious about security, here is what I would tell you.

1. Pay attention to patterns. Keep notes on recurring issues. Ask why they happen, not just how to fix them.
2. Learn the network. Understanding TCP/IP, DNS and how traffic flows will make you better at both support and security.
3. Build something at home. A small lab teaches more than any course on its own. Start with a spare machine and a free Linux distribution.
4. Talk to your security team. Ask what they wish support staff would flag. You'll learn what matters, and they'll remember you.
5. Get one credential at a time. Choose a certification that fits the role you want, and use it to structure your learning rather than just to collect letters.

What's next in this series

Over the coming weeks I'll be writing about the practical side of networks and security: troubleshooting DNS, triaging tickets, spotting phishing, building a home lab, digital forensics, VPNs, least privilege and more. Each article will draw on what I've learned on the job and in study, and I'll keep things clear enough for anyone to follow.

If you work in IT support or security, I'd love to hear your story. What first made you think about moving into security, or what keeps you in support?