Passwords alone are not enough to protect something as valuable as your AWS account. In this subchapter, we’ll look at two mechanisms that greatly enhance security: Multi-Factor Authentication (MFA) and temporary credentials (STS). They are the difference between a vulnerable account and a well-protected one.

MFA stands for Multi-Factor Authentication. The idea: to log in, it’s not enough to know something (the password); you also have to have something (a code that changes every few seconds on your phone).

The “factors” of authentication are of three types:

• Something you know: a password.
• Something you have: your phone with a code app, or a physical key.
• Something you are: your fingerprint, your face (biometrics).

MFA combines at least two of these factors. The most common is password (know) + phone code (have).

Analogy: It’s like an ATM. To withdraw money you need the card (something you have) and the PIN (something you know). With only one of the two, you can’t. If someone steals your card but doesn’t know the PIN, they can’t withdraw money.

The big advantage: even if an attacker steals your password, they can’t get in without the second factor, which is physically on your phone.

Real example: An attacker gets your AWS password through a phishing email. They try to log in… but AWS asks for the MFA code, which only appears on your phone. The attacker is locked out. The stolen password alone is useless.

According to security studies, enabling MFA blocks the vast majority of automated account theft attacks. It’s one of the most effective and cheapest security measures out there.

• You can use an authenticator app (Google Authenticator, Authy, Microsoft Authenticator…) that generates 6-digit codes that change every 30 seconds.
• Or a physical security key (like a YubiKey) for maximum protection.

Absolute golden rule: ALWAYS enable MFA on the root user, no exceptions. The root has total power over your account; protecting it with MFA is the first thing you should do when creating an account. And enable it for all users with important permissions. We’ll review this in subchapter 7.5.

Before talking about STS, let’s understand the problem it solves.

An IAM user can have permanent access keys to program against AWS. The problem: those keys never expire. If they leak (uploaded to GitHub by mistake, stolen from a laptop…), an attacker can use them indefinitely until someone notices and disables them.

Permanent credentials are like a key that never expires: convenient, but dangerous if lost.

STS stands for Security Token Service. Its function: to generate temporary credentials that expire automatically after a while (from a few minutes to a few hours).

Analogy: STS credentials are like a hotel key card. It gives you access to your room, but stops working the day you leave. You don’t have to return it or worry: it expires on its own. If you lose it, the damage is limited because it will soon stop working.

The fact that they expire on their own drastically reduces the risk: a stolen credential that stops working in an hour is much less dangerous than one that lasts forever.

Remember roles from subchapter 7.1? Here’s the magic: when someone (or something) “assumes a role,” STS gives them temporary credentials with the permissions of that role.

This is exactly what happens when:

• An EC2 instance assumes a role to read S3 (STS gives it temporary credentials behind the scenes).
• A Lambda function accesses a database (same mechanism).
• A user from another account assumes a role to access your resources (cross-account).

Why this is huge for security: With roles + STS, there are no permanent keys stored anywhere. The EC2 instance doesn’t have a file with keys someone could steal; it gets temporary credentials that renew and expire automatically. That’s why the best practice from subchapter 7.1 (“use roles, not keys on the server”) is so important.

The professional and secure way to work:

1. People: log in with user + password + MFA. For advanced tasks, assume roles (temporary credentials).
2. Services and applications (EC2, Lambda, etc.): use roles, never embedded permanent keys.
3. Permanent access keys: avoided whenever possible. If used, rotate them frequently.

Modern tools like AWS IAM Identity Center (formerly AWS SSO) make it easy to give people access with temporary credentials and MFA centrally, without permanent keys.

• MFA adds a second factor (a code on your phone) in addition to the password: even if your password is stolen, they can’t get in. Always enable it on root and important users.
• Permanent credentials (access keys) are dangerous because they don’t expire: if leaked, they work indefinitely.
• STS generates temporary credentials that expire automatically, greatly reducing risk (like a hotel key card).
• When assuming a role, STS delivers those temporary credentials. That’s why roles + STS allow services like EC2 or Lambda to access resources without storing permanent keys.
• Best practice: people with MFA, services with roles, avoid permanent keys.

In the last IAM subchapter, we’ll bring everything together in a list of security best practices you should always apply.