#4 I Thought Hacking Meant Freedom. Then I Took a Course That Told Me Otherwise.

In my mind the term hacker used to mean something to a rebel. The hacker is someone who bends the rules and breaks into systems that nobody else can get into. They only answer to their curiosity. I think that a lot of people who get into cybersecurity have this image of a hacker in their head. We see it in movies and on forums. We like the way it looks. The idea of the hacker is really cool, to us.

I just finished the Ethical Hacking Fundamentals course from IBM on Coursera which's the first course in the Ethical Hacking specialization that IBM offers. This course really changed my view of Ethical Hacking. It did not make Ethical Hacking sound boring to me. Ethical Hacking is still one of the interesting things I have learned about.. The course showed me what Ethical Hacking is really like. It showed me where the exciting ideas, about Ethical Hacking end and the actual work of Ethical Hacking begins. I think this is a thing to learn about Ethical Hacking.

This one is for anyone who's ever thought "ethical hacking" sounds like a loophole. It isn't. It's one of the most tightly bounded professions in tech, and this newsletter is my attempt to lay out what I learned, as clearly as I can, for anyone standing where I was a few weeks ago.

The One Idea the Entire Course Is Built On

If I had to compress the whole certificate into a single sentence, it would be this:

Good intentions are not a legal defense.

That's it. That's the line the entire course keeps circling back to. It doesn't matter how skilled you are, how harmless your motives were, or how clearly you can explain that you were "just trying to help." The moment you access a system without explicit, written, prior authorization, you are — legally — in the same category as someone with genuinely malicious intent. The law generally does not ask why you got in. It asks whether you were allowed to.

That single idea rewired how I think about this entire field.

Misconception #1: "If I don't cause harm, I can't get in trouble"

I thought that long as nothing got broken and no information was taken, looking around a system was not a big deal. This course really changed my mind about that. With laws like the US Computer Fraud and Abuse Act just getting into a system without permission is against the law. You do not have to want to cause trouble for it to be a problem. Even if you are just looking around with no intentions you can still get in trouble. The problem is getting into the system not just what you do after you are in the Computer Fraud and Abuse Act system. The Computer Fraud and Abuse Act says that getting into a system without permission is the crime it is not about what you do once you are, inside the system.

Misconception #2: "Verbal permission is still permission"

Another one I didn't question until now. A client saying "sure, go ahead and test it" in a call or a message feels like enough. It isn't. Courts don't recognize verbal or implied consent as legal protection. Without a signed, written agreement defining scope, timeline, and boundaries, a "yes" from a client is legally worth very little if something goes wrong later.

Misconception #3: "Publicly visible vulnerabilities are fair game"

This was the one that surprised me the most. If a problem is sitting there on a public-facing website. No hacking, nothing hidden. Surely just looking at it and reporting it in the right way is okay? According to the course no. Actively interacting with or testing a system without written permission can still be considered unauthorized access even for something anyone could find by accident. A 2017 case involving a researcher who responsibly shared a problem on a US airlines public website without asking first is used in the course to make exactly this point. The sharing was done with good intentions, but the lack of written permission still led to serious professional consequences.

Misconception #4: "I was hired, so I'm covered"

Being formally hired does not automatically keep you safe if you do something that's not part of the agreement. The course looks at what happened with Coalfire in 2019. Two people who test security called penetration testers were legally allowed to test the security of a courthouse.. They were arrested after they went into the building when it was closed. They thought they were doing what they were supposed to do. The police did not agree because the testers did not follow the rules about when they could be in the building. The lesson is very clear: the rules about what you're allowed to do are not just suggestions they are what make something legal. The Coalfire case shows that the scope of authorization is, like a fence that you must stay inside the scope of authorization is what keeps you safe the scope of authorization is very important.

The Three Types of Hackers, Properly Defined

The course also cleared up something I'd always used loosely:

White hat hackers — work with explicit permission from organizations to find and fix vulnerabilities. This is where "ethical hacking" as a profession lives.
Black hat hackers — breach systems illegally, for personal gain, disruption, or malicious intent. No permission, no ethics.
Gray hat hackers — the murky middle. They sometimes find vulnerabilities without permission but disclose them responsibly rather than exploiting them. Not malicious, but still legally exposed, since the absence of authorization is what matters most, not the absence of bad intent.

Same methodology across all three — reconnaissance, scanning, gaining access, maintaining access, covering tracks. What separates a white hat from a criminal isn't skill. It's paperwork and permission.

What Actually Protects an Ethical Hacker

Stripped down, the course keeps coming back to the same four preconditions before any testing begins:

Explicit written consent from the legitimate system owner
A pre-test agreement defining exact scope, tools, and timeline
A responsible disclosure process for anything you find
Jurisdictional awareness — knowing whose laws apply, based on where the systems, data, and users actually are

And when a vulnerability is found, it isn't a free-for-all either. The course lays out responsible disclosure as a structured six-step process: confirm the vulnerability, check the legal boundaries, find the right contact, report privately, give the organization 30–90 days to fix it, and only then consider a public write-up — and only once a fix is confirmed live.

Why This Actually Changed How I See the Field

I started this course thinking I would learn about tools and techniques.. What I really got was something much more important. I learned that ethical hacking is not just about what you can do. It is about being disciplined and staying within the rules. These rules are not always clear.

I used to think that hacking meant I could do whatever I wanted.. That is not true, for professional hackers. What is important is that people trust you. Organizations trust hackers to access their systems. The law trusts hackers to not abuse this access. This trust is the basis of the profession of ethical hacking. Ethical hacking is built on trust.

If you're early in your cybersecurity journey like me, this is worth internalizing before you touch a single tool: your intentions will never be the thing that protects you. Your paperwork will.

LINK TO THE COURSE CLICK HERE

This is part of my ongoing build-in-public series documenting my path into cybersecurity — one course, one certificate, one misconception corrected at a time

Contents