Identity & Access Management

Monday morning. The intern. The production database. Gone.

It was 9:47 AM when the Slack channel exploded.

Jake — the summer intern who had been at the company for exactly eleven days — ran a cleanup script he found on Stack Overflow. He thought he was running it against the test database. He was not. He was running it against production. The script had one job: DELETE FROM customers WHERE created_at < '2024-01-01'. It did that job beautifully.

In twelve seconds, 340,000 customer records vanished.

The engineering team scrambled. The VP of Engineering turned white. The CEO called an emergency meeting. The CTO asked the question everyone was thinking: "Why did the intern have admin access to the production database?"

Nobody had an answer. When Jake was onboarded, someone gave him the same access credentials as the senior engineers. It was faster. Nobody thought to create a restricted account. Nobody thought about it at all.

The database was restored from a backup four hours later, but those four hours cost the company an estimated $180,000 in lost revenue, three enterprise customers who threatened to leave, and the trust of an engineering team that now had to explain this to regulators.

Jake did nothing malicious. He made a mistake that any human could make. The failure was not Jake. The failure was that nobody controlled who could do what.

That failure has a name: Identity and Access Management — or IAM.

Authentication vs. authorization — two different questions

IAM boils down to two questions that sound similar but are completely different:

1. Authentication: Who are you? — Proving your identity.
2. Authorization: What are you allowed to do? — Determining your permissions.

Here is the analogy that makes it stick. Think about a hotel.

When you check in at the front desk, you show your ID. The receptionist verifies that you are who you claim to be. That is authentication — proving your identity.

Then the receptionist gives you a key card. That key card opens your room on the 4th floor. It does not open the penthouse suite. It does not open the staff-only maintenance closet. It does not open other guests' rooms. The key card determines what you can do. That is authorization — defining your permissions.

Jake at the hotel would have checked in (authentication) and received a master key that opens every room, the kitchen, the safe, and the manager's office (authorization failure). No hotel does this. But companies do it with database access every day.

There Are No Dumb Questions

"If I am authenticated, am I automatically authorized?"

No. Authentication proves who you are. Authorization decides what you can do. You can be authenticated (we know you are Jake the intern) and still be denied access to production systems (you are not authorized). These are independent checks. A common mistake is treating them as the same thing — "if they logged in, they must be allowed."

"Can you be authorized without being authenticated?"

In rare cases, yes. A public website authorizes everyone to view content without authenticating them. But for anything sensitive, authorization should always require authentication first. You would never give a hotel key card to someone who did not show ID at the front desk.

Password security: why "Password123!" is terrible

Let us start with the most basic form of authentication: the password. And let us start with why most people are doing it wrong.

Here are the five most common passwords, year after year:

1. 123456
2. password
3. 123456789
4. qwerty
5. 12345678

If your password is on this list, an attacker does not need to hack anything. They just try the top 100 passwords against your account, and they are in within seconds. This is called a dictionary attack — trying common passwords from a pre-built list.

"But I use Password123!," you say. "It has uppercase, lowercase, numbers, AND a special character!"

It does not matter. Password123! follows such a predictable pattern (capital first letter, numbers at the end, exclamation mark to satisfy the special character requirement) that it appears in every attacker's dictionary. It is the equivalent of hiding your house key under the doormat and thinking you are clever because you put it under the left side of the doormat.

What actually makes a password strong?

The passphrase approach is the sweet spot. Four random, unrelated words strung together create a password that is extremely long (making it hard to crack) but easy to remember (because your brain is good at stories and images). Imagine a correct horse kicking a battery that is shaped like a staple. Ridiculous? Yes. That is why you remember it.

Multi-Factor Authentication: the lock, the deadbolt, and the alarm

A password is something you know. But what if someone else also knows it? If your password is the only thing protecting your account, a single leak takes everything.

Multi-Factor Authentication (MFA) requires two or more different types of proof. The three types are:

MFA means combining at least two different types. Using two passwords is NOT MFA — that is just two things you know. Using a password (know) plus a fingerprint (are) IS MFA.

Think of it like your house. A password is the lock on the front door. MFA adds a deadbolt (your phone must approve the login) and an alarm system (your fingerprint). A burglar who picks the lock still faces the deadbolt and the alarm. Each layer is independent — defeating one does not defeat the others.

Why SMS is the weakest form of MFA

SMS codes — the six-digit codes texted to your phone — are better than nothing but worse than everything else. Here is why:

SIM swapping is the killer. An attacker calls your phone carrier, convinces them to transfer your number to a new SIM card, and now they receive your SMS codes. This has been used to steal millions in cryptocurrency. In 2019, Twitter CEO Jack Dorsey's account was hijacked this way.

There Are No Dumb Questions

"What if I lose my phone? Am I locked out forever?"

No. When you set up MFA, the service gives you backup codes — one-time-use codes you can store somewhere safe (printed on paper in a locked drawer, saved in a password manager). If you lose your phone, you use a backup code to get in and reconfigure MFA on a new device. Always save your backup codes.

"Is biometric authentication really secure? Someone could copy my fingerprint from a glass I touched."

Theoretically, yes. Researchers have demonstrated lifting fingerprints and creating silicone molds. But this requires physical proximity, specialized equipment, and effort that puts it far beyond most attackers. For 99.9% of people, biometrics are very secure. The real risk is that you cannot change your fingerprint if it is compromised — unlike a password, you cannot get new fingers. This is why biometrics work best as one factor combined with others, not as the sole factor.

Single Sign-On: one key for every door

You log in to Gmail. Then you open Google Drive, Google Calendar, YouTube, and Google Docs — all without logging in again. That is Single Sign-On (SSO).

SSO lets you authenticate once and access multiple applications without re-entering credentials. One identity, many services.

The workplace version: you log in to your company's identity provider (like Okta, Microsoft Entra ID (formerly Azure AD), or Google Workspace) once in the morning. For the rest of the day, you click into Slack, Jira, Salesforce, GitHub, and your HR system without another password prompt. The identity provider vouches for you each time: "Yes, I already checked — this is Sarah from engineering."

Why SSO matters for security:

• Fewer passwords = fewer passwords to steal, reuse, or forget
• Central control = IT can disable one account and instantly revoke access to all connected apps
• Better MFA = enforce MFA once at the identity provider level, protecting every app behind it
• Faster offboarding = when someone leaves the company, disable their SSO account and they lose access to everything simultaneously

Role-Based Access Control: the "need to know" principle

Back to Jake the intern. The fix is not "never hire interns." The fix is to give Jake access to exactly what he needs — and nothing more.

Role-Based Access Control (RBAC) assigns permissions based on your role in the organization, not your individual identity. Instead of saying "Jake can read the test database," you say "Interns can read test databases. Jake is an intern. Therefore Jake can read test databases."

Think of it like military security clearances:

A private (unclassified clearance) cannot walk into a room full of top-secret documents just because they are in the army. They need the clearance — the role — that grants access.

In RBAC, a typical setup might look like this:

Jake was an intern given database admin permissions. In an RBAC system, that cannot happen — the role defines the access, and the role is assigned based on job function.

Principle of Least Privilege: the minimum viable access

RBAC is the system. Least Privilege is the philosophy behind it.

The Principle of Least Privilege says: every user, program, and process should operate with the minimum set of permissions needed to complete their task. No more, no less.

You do not give the intern the nuclear launch codes.

You do not give the receptionist access to the payroll system.

You do not give the marketing team write access to the production database.

You do not run your web server as root.

There Are No Dumb Questions

"But giving everyone limited access is so inconvenient. People constantly need to request more access."

Yes. That friction is a feature, not a bug. The small inconvenience of requesting elevated access is the price you pay to avoid the massive inconvenience of explaining to regulators why the intern deleted the production database. Most organizations use a request-and-approve workflow — you request access, your manager approves it, and it is granted (often with an expiration date). The two minutes to submit a request prevent the four-hour outage.

"What about break-glass procedures?"

Great question. Sometimes you need emergency access — a production system is down at 3 AM and the only person with access is on a plane. "Break-glass" procedures provide emergency elevated access that is heavily logged, time-limited, and reviewed after the fact. Like a fire alarm behind glass — you can break it if there is a real emergency, but everyone will know you did.

Zero Trust: never trust, always verify

Traditional security works like a castle with a moat. Once you are past the drawbridge (the firewall, the VPN), you are trusted. You can roam freely inside the castle walls.

Zero Trust says: there is no "inside."

Every request — whether it comes from the CEO's laptop in the headquarters building or a contractor's phone at a coffee shop — must be verified. Every time. No exceptions.

The old model trusted the network: "You are on the corporate Wi-Fi, so you must be an employee." Zero Trust trusts nothing: "I do not care where you are connecting from. Prove who you are, prove your device is secure, and I will give you access to only what you specifically need for only as long as you need it."

Zero Trust in practice means:

1. Verify explicitly — always authenticate and authorize based on all available data: user identity, location, device health, service, data classification
2. Use least privilege access — limit access with just-in-time and just-enough-access policies
3. Assume breach — minimize the blast radius by segmenting access, verifying end-to-end encryption, and using analytics to detect anomalies

Google built one of the first large-scale Zero Trust implementations called BeyondCorp after the 2009 Operation Aurora attack (a sophisticated nation-state attack that penetrated Google's corporate network). Their conclusion: the perimeter cannot be trusted. Every employee at Google now accesses internal tools the same way whether they are in the office or at home — through the same identity verification, device checks, and per-request authorization.

Common IAM attacks: how attackers break through

Understanding how attackers exploit IAM weaknesses is essential for defending against them.

Credential stuffing is particularly devastating because of password reuse. If you use the same password for your email and your bank, and your email provider gets breached, attackers do not hack your bank — they log in with your stolen credentials. From the bank's perspective, it looks like a legitimate login.

That last statistic is worth repeating: MFA stops 99% of automated account attacks. It is not a silver bullet, but it is the closest thing cybersecurity has to one.

IAM careers: one of the fastest-growing specializations

IAM is not just a topic — it is an entire career path. As companies adopt Zero Trust architectures and cloud-first strategies, the demand for IAM specialists has exploded.

If you are interested in cybersecurity but do not want to focus on hacking or incident response, IAM is an excellent path. It sits at the intersection of security, IT operations, and governance — and every organization, from startups to Fortune 500 companies, needs it.

Back to Jake the intern

Jake deleted 340,000 customer records in twelve seconds — not because he was malicious, but because someone gave him the same admin credentials as the senior engineers on his first day. If the company had applied least privilege and RBAC, Jake would have had read-only access to the test database and no access to production at all. The $180,000 in lost revenue, the four-hour outage, and the regulatory fallout were all preventable with one question nobody asked during onboarding: "What does this person actually need access to?"

Key takeaways

• Authentication proves who you are; authorization determines what you can do — they are independent checks, and confusing them is how interns get admin access
• Passwords alone are broken — use a password manager, passphrases, and unique credentials per site
• MFA stops 99% of automated attacks — use authenticator apps or hardware keys over SMS
• SSO centralizes authentication, reduces password sprawl, and makes offboarding instant
• RBAC and least privilege ensure people have the minimum access their role requires — no more
• Zero Trust assumes breach and verifies every request regardless of network location
• Credential stuffing exploits password reuse — it is the reason one breach leads to many
• IAM is a fast-growing career with strong salaries and demand across every industry