The previous lesson closed with twelve prioritised measures for Nimbus, and number one was MFA. That was no accident: several of the others also revolve around the same question — who you are and what you can do. When half the headcount works outside the office, the data is in the cloud, a consultancy has remote access and the API is consumed by a mobile app, the perimeter stops being a line on the network. What is left between an attacker and the clinics' diaries is a credential and an authorisation decision. This lesson develops both: the life cycle of an identity and orphaned accounts, what the current guidance says about passwords, the forms of MFA ordered by their real phishing resistance, SSO and the identity protocols with the exact difference between OAuth 2.0 and OpenID Connect, sessions and JWTs with their correct validation as against the naive one, the five authorisation models with Nimbus's concrete design, and privileged accounts with just-in-time access and recertification.

1. Identity as the new perimeter
2. The identity life cycle and orphaned accounts
3. Authentication factors and their weaknesses
4. Passwords: what the guidance says today
5. MFA ordered by phishing resistance
6. SSO, federation and identity protocols
7. Sessions and tokens: cookies and JWTs
8. Authorisation models and Nimbus's RBAC
9. Multi-tenancy and isolation
10. Privileged, service and third-party accounts
11. Recertification: the periodic access review

The classic model divided the world into inside and outside, and put the control on the boundary. That model describes Nimbus's reality less and less well:

The only thing that crosses all of those contexts is identity. If an attacker obtains Lucía's credentials, they do not need to get through any firewall: they walk in through the front door of every one of those systems, from anywhere in the world, and everything they do will look legitimate.

Hence the formulation that sums up the Zero Trust approach of 01-03 applied to this domain:

Identity is the new perimeter. A request is not trusted because it comes "from inside"; it is trusted because you can verify who is making it, with what device, for which resource and under what conditions, on every request.

Three concepts that must be separated precisely, because they are constantly confused:

And the recurring trap: most serious incidents are not authentication failures, they are authorisation failures. The IDOR of 01-01 happened with a perfectly valid session. Authenticating well and authorising badly is the number one pattern in the OWASP Top 10.

An identity is not a static record: it is a process with three moments, and it is the third that almost always fails.

The four requirements of a correct joining process:

1. Based on the role, not on a copy. The classic mistake is "give them the same permissions as Iván". That also copies the permissions Iván accumulated on old projects, and privilege spreads like an infection. There must be a predefined access profile per role.
2. With a recorded approval from the asset owner (the "owner" field of the 01-04 inventory exists for exactly this).
3. With an expiry date if it is temporary. An intern, a three-month contract or a consultancy must have an end date in the system, not in somebody's memory.
4. With a named identity. No shared accounts: without a named identity there is no traceability, and without traceability there is no non-repudiation (01-01).

This is the silent problem. Rubén joined support, helped out in billing for six months, took part in the data migration and now coordinates the team. If at each change permissions were added without withdrawing the previous ones, Rubén today has more access than anybody else at Nimbus, and nobody ever decided that.

The rule: every role change is a removal of the old role and a grant of the new one, not an addition. And every temporary permission is created with an end date.

A developer leaves Nimbus. Lucía deactivates his mail account the same day and considers the process finished. Six months later, during the inventory review, this turns up:

Eight live accesses belonging to somebody who no longer works here. And none of them shows up on a firewall, because technically all of them are legitimate.

Why orphaned accounts are especially dangerous, beyond the obvious:

• Nobody watches them. Anomalous use of Lucía's account might get noticed; nobody misses dev_carlos.
• Nobody maintains them. Their password is not rotated, MFA is not added when it is rolled out, their permissions are not reviewed.
• They are the preferred target of credential stuffing. If that person reused the password and it appears in another service's breach, the door is still open.
• There is not always malicious intent. The ex-employee who keeps logging in "to help" creates an equally serious problem: access with no current authorisation and no control.

The correct leaving procedure for Nimbus:

The two points most often forgotten are the revocation of sessions and tokens — deactivating an account does not invalidate an already-issued session, as you saw with pass-the-cookie in 02-03 — and the rotation of shared secrets: if that person knew the NAS password or the gateway key, those credentials are compromised by definition.

The structural measure that halves the problem: the more systems are federated with a single identity provider, the fewer boxes there are to tick. That is the main reason SSO is a security measure and not merely a convenience.

A factor is a category of proof. Multi-factor authentication requires factors of different categories; two passwords are not two factors.

Three clarifications that correct frequent misunderstandings:

1. Biometrics almost never travel to the server. When Iván unlocks his phone with his fingerprint, the biometric data does not leave the device: it unlocks a private key stored in the secure hardware. What the service receives is a cryptographic proof. That distinction is what makes passkeys robust rather than a privacy problem.
2. Security questions are not a factor, they are a worse password: the answer is usually public or guessable, and you cannot change the name of your childhood school.
3. Context does not replace a factor, but it is enormously valuable in combination: requiring reauthentication when the country or the device changes is what turns a stolen token into a useless one.

The recommendations changed substantially over the last decade, and many organisations are still applying the 2005 ones — which make security worse. The current reference is the NIST SP 800-63B guidance.

Checking against leaked lists is the single most effective measure in this table, and the least implemented. It stops somebody choosing a password that is already in the dictionaries attackers use. It is implemented without sending the password anywhere: the first characters of the hash are sent and the rest is compared locally (the k-anonymity model).

Password managers. For Nimbus they are mandatory, and the argument is simple: they make it possible to do the one thing that really matters — a long, random, per-service password — without memorising anything. The usual objection ("what if the manager is compromised?") ignores the real alternative, which is not memorising 40 strong passwords: it is reusing three weak ones. A manager with a strong master password and MFA is, by an enormous margin, the safest option. An added and little-known benefit: the manager does not fill in credentials on a domain that does not match, which turns it into a passive phishing detector.

The secure storage of passwords on the server — why they are never kept in the clear or with a plain hash, and what bcrypt, scrypt and Argon2 are, with their cost factor and their salt — is studied in detail in 03-04. Here the rule is enough: Nimbus never stores recoverable passwords, and no legitimate process can give a customer back their current password.

MFA is the most cost-effective measure in the lesson, but not all forms of MFA are worth the same. The decisive difference is whether the second factor can be captured and reused by an interposed attacker.

All the previous methods share one underlying defect: they produce a secret the user transmits. If the user is on a fake website, they transmit the secret to the attacker, who relays it to the real site within seconds. That is exactly what reverse-proxy phishing kits do, and it is why "we have MFA" stopped being a sufficient answer.

FIDO2 breaks that scheme with two properties:

1. The private key never leaves the device. There is no secret the user could hand over, not even if they wanted to.
2. The signature is bound to the domain (origin binding). The browser includes the page's real origin in the operation. If the user is on nimbusreservas.example.portal-facturas.example, the key produces a signature for that domain, which the legitimate server rejects. The attack does not fail because the user notices: it fails because it is cryptographically invalid.

Put another way: with TOTP or SMS, the defence depends on the user spotting the fake site. With FIDO2, the defence works even if the user spots nothing. That is the difference between a measure that depends on human judgement and one that does not. Remember the principle from 02-03: if your defence requires 38 people to get it right every time, you have no defence.

Passkeys are FIDO2 with the key synchronised between the user's devices through their ecosystem, which removes the main friction (losing the key) in exchange for trusting the synchroniser.

Even if the target is FIDO2, TOTP remains the realistic minimum for many accounts. It is worth understanding how it works inside.

The four decisions that separate this implementation from a naive one:

• (a) A bounded tolerance window. With no tolerance, users whose clock is slightly off cannot get in. With a large window (say ±5), the code is valid for almost five minutes and the real-time attack becomes trivial. ±1 is the usual balance.
• (b) hmac.compare_digest. A normal string comparison stops as soon as it finds a difference, and that time is measurable. In constant time nothing leaks.
• (c) Single-use consumption. It is the control most often forgotten: without it, a code captured by phishing remains valid for the rest of the window, which is exactly what the interposed attacker needs.
• The secret is stored encrypted in the database, not in the clear: anyone who reads it can generate codes indefinitely.

And the honest conclusion: however well implemented it is, TOTP is still phishable, because the user types a code into a page. That is why the direction of travel for Nimbus is TOTP as the general minimum and FIDO2 for anything administrative.

Connecting with 02-03: notification bombing exploits the fact that approving is a button with no context. The fixes, in order of effectiveness:

1. Number matching: it forces you to look at the originating screen and enter a number, which makes approving out of inertia impossible.
2. Context in the notification: application, approximate location, device. A request from another country is obvious.
3. Attempt limits: after 3 denied or ignored requests, the account is locked and an alert fires.
4. Alert to security on bursts: a burst of MFA requests means somebody already has the password, whether it gets approved or not. It is a high-value signal that hardly anybody watches.

With single sign-on, the user authenticates once to an identity provider and reaches every federated application.

The counterweight, which has to be accepted consciously: the identity provider becomes the most critical asset of all. If it goes down, nobody gets into anything; if it is compromised, everything is compromised. Hence: mandatory FIDO2 MFA for its administrators, exhaustive logging, and an emergency access procedure with credentials kept offline for the case of unavailability.

It is the most widespread confusion in the domain, and it produces insecure systems.

The sentence to fix in your mind: OAuth 2.0 is not an authentication protocol. Using an access token as proof of identity is a classic mistake: that token says what can be done, not who you are, and it might have been issued for a different application. If what you need is "who is this user", use OIDC and validate the ID token.

SAML is the veteran: the same objective as OIDC (federated authentication), based on XML and signed assertions, very widely deployed in the corporate world. For new integrations OIDC is preferred for its simplicity and its natural fit with mobile applications and SPAs; SAML is still unavoidable when a large corporate customer demands it, and that is a common request for a B2B SaaS like Nimbus.

Why PKCE is essential and not an optional extra. The authorisation code travels through the browser, and in a public application (an SPA or a mobile app) there is no way of keeping a client secret: anyone can decompile the app or read the JavaScript. If an attacker intercepts the code, they could exchange it for tokens.

PKCE prevents this with a simple idea: the application generates a random value (code_verifier), sends only its hash when starting the flow, and presents the original value when exchanging. Whoever does not have the code_verifier cannot use the stolen code, and that value never leaves the browser that started the flow.

The four common mistakes in this flow:

• Using the implicit flow (tokens in the URL): obsolete and discouraged.
• Storing the tokens in localStorage: reachable from JavaScript, and therefore stealable with an XSS. A HttpOnly cookie managed by a server-side intermediary is preferable.
• Not validating aud in the API: accepting a token issued for another application.
• Not validating the state parameter: it is the CSRF protection of the authentication flow itself.

SameSite=Strict versus Lax: Strict is safer but breaks navigation from external links (the user arrives at the panel and appears not to be logged in). Lax is the usual balance; for sensitive operations it is combined with an anti-CSRF token.

A JWT has three parts separated by dots: header, payload and signature, encoded in base64url.

The first thing to understand, and the most misinterpreted: a JWT is signed, not encrypted. Anyone holding it can read its contents with no key at all. The signature guarantees integrity and origin, not confidentiality.

What must NEVER go inside a JWT:

What it should carry: a subject identifier (sub), the tenant, the minimal roles or scopes, and always iss, aud, exp, iat and jti.

The three flaws and why each is exploitable:

1. With no signature verification, an attacker composes a JWT with "roles": ["admin"] and "tenant_id": 7 and walks in as administrator of any clinic. The historical variant of this flaw is accepting the none algorithm that the token itself declares in its header: the token's alg must never be trusted to decide how to validate it.
2. With no exp check, a token stolen a year ago still works. Without iss and aud, a valid token issued by another system or for another application is accepted here.
3. Blindly trusting the roles in the token means that a permission change or a leaver has no effect until the token expires.

The seven decisions, explained:

1. Keys from JWKS by kid. It allows the signing key to be rotated without touching the API. Hard-coding the public key turns rotation into a deployment, and what is hard does not get done.
2. algorithms=["RS256"] fixed. It closes off the algorithm confusion attack (for example, passing the RSA public key off as an HMAC secret).
3. and 4. issuer and audience. Without aud, a legitimate token for another service from the same issuer would be accepted by the Nimbus API.
4. leeway. It avoids spurious failures caused by clock drift; 30 s is reasonable, minutes are not.
5. Revocation by jti. This is the JWT's structural weak point: being self-contained, it is valid until it expires even if the user has left. A revocation list with the same lifetime as the token solves the problem at minimal cost.
6. Current permissions from the source of truth. The roles in the token serve as a quick hint; sensitive decisions are taken with up-to-date data.

Refresh rotation with reuse detection, which is the elegant piece: if a refresh token that has already been used is presented again, it means somebody holds a stolen copy. The correct response is to invalidate the whole token family of that session and force reauthentication. It is a theft detection mechanism that works with no extra infrastructure.

Recall the finding: the nimbus-deploy-bot service account with a personal token with no expiry and write permissions on every repository. It was also the first link of the chained attack of 02-02.

Everything that is wrong with it:

The fix, in order of preference:

1. Remove it and use short-lived credentials from the CI itself (a short-lived federated identity issued for each run). The best secret is the one that does not exist.
2. If that is not possible: an application token with per-repository scope, a 90-day expiry, automated rotation and storage in the secrets manager.
3. In any case: an alert on any use from an unexpected IP and a quarterly review of live tokens.

Tokens unused for 30 days are as dangerous as eternal ones, and for the same reason as orphaned accounts: nobody would miss them if somebody started using them.

Authentication answers "who you are". Authorisation answers "what you can do", and it is where most serious incidents happen.

What suits Nimbus: RBAC as the base, with attributes for the conditions. It is the hybrid model almost everybody uses: roles define the bulk of the permissions and a few contextual rules cover what roles do not express (the tenant, working hours, the device).

Customer roles (inside a clinic or gym):

Nimbus internal roles:

Four decisions in this design that deserve attention:

1. practitioner uses an attribute (assigned_diary), not a role. "Their" patients cannot be expressed with roles alone: it is a relationship between the user and the resource. This is where pure RBAC falls short and ABAC/ReBAC gets added.
2. impersonate_user is an explicit permission with conditions, not an implicit capability of the support role. It is the fix for the "view as customer" feature that allowed access to 40 clinics in the 02-02 exercise. And the customer is notified: transparency is itself a control.
3. audit:delete appears as an explicit denial for everybody, including systems. It is the separation of duties from 01-03: whoever administers cannot delete the proof of what they did, consistent with the INSERT without UPDATE for nimbus_api.
4. The file lives in the repository. A permission change goes through review and stays in the history. Permissions changed by hand in a console leave no comprehensible trace.

And in the database, the counterpart of the same design, consistent with the roles from 01-03:

Nimbus is multi-tenant: a single database with the data of every clinic. Isolation between customers is the product: if it fails, there is no business.

You have already worked on the two pieces — the tenant_id filter that fixed the IDOR in 01-01 and the row level security (RLS) that makes it mandatory at the engine in 01-03. What belongs here is how isolation fits into access control:

The design rule, in one sentence: the tenant_id never comes from a parameter sent by the client; it always comes from the token validated on the server. An endpoint that accepts ?tenant_id= from the client is an IDOR by another name.

And the check worth automating: a test in CI that, with one tenant's token, tries to reach another tenant's resource and requires a 404. It is a five-line test that would have caught the original IDOR before it reached production.

Accounts with elevated permissions are the ultimate objective of almost any attack. They deserve different treatment from the rest.

The problem: if Lucía browses, reads mail and administers the infrastructure with the same account, a successful phishing attack against her mail hands over control of all of production directly.

The solution: two identities for the same person.

The cost is a moderate daily inconvenience; the benefit is that the most likely vector (phishing the mailbox) stops leading to the most critical asset.

PAM (privileged access management) groups together the practices for controlling the most powerful accounts:

The mental shift just-in-time proposes: instead of asking "who should have permanent access?", you ask "why would anybody have permanent access?". In a well-designed system, the normal state of an administrative account is without privileges; privileges are granted for minutes and disappear on their own. It is the least privilege principle of 01-03 taken to the axis of time: not only the minimum of permissions, but also the minimum of duration.

This is the asset with critical criticality and Marta as owner in the 01-04 inventory, and it is the exact pattern of the Target incident we will analyse in 02-06.

Current situation:

Target configuration:

1. Named accounts per consultancy engineer. No exceptions: without naming there is no non-repudiation.
2. Mandatory MFA on every access.
3. Just-in-time access: no privileges by default; they are requested with a reason, approved by Lucía or Marta and expire within hours.
4. Bounded scope: only the systems they genuinely need, never "administrator of everything".
5. Logged sessions, reviewed by sampling.
6. Automatic expiry of the access aligned with the contract, with a quarterly review.
7. An alert on any access outside the agreed window.

Note: the contractual obligations with the supplier — scope, confidentiality, incident notification, subcontracting, audit — and third-party risk management as a process are covered in 04-04, and their data protection implications in 06-03. They must be validated with legal advice.

The accounts used by systems (not by people) are the usual blind spot: nobody claims them and nobody reviews them.

Everything above degrades over time. Recertification is the periodic review in which the owner of each asset confirms — or withdraws — the access that has been granted.

How it is done at Nimbus, sustainably:

The piece of data that makes the review efficient is the date of last use. A permission unused for six months is almost never necessary, and presenting the list sorted by that field turns a tedious review into a quick decision.

A "NEVER USED" permission is the best possible news in a recertification: it is withdrawn without discussion, with no risk of breaking anything and with an immediate benefit in surface reduction.

Common mistakes:

• Only offboarding the mail account. It is the mistake of section 2.3: eight accesses stay alive in non-federated systems.
• Deactivating the account without revoking sessions and tokens. An issued session keeps working; a token with no expiry, forever.
• Copying another employee's permissions when onboarding. It propagates accumulated privileges nobody decided to grant.
• Treating all MFA as equivalent. SMS and FIDO2 differ in whether the phishing attack works or not.
• Forcing password expiry every 90 days. It produces trivial variations and passwords written on paper; the current guidance advises against it unless there is an indication of compromise.
• Using OAuth 2.0 as if it were authentication. An access token says what can be done, not who you are. For identity, OIDC and validation of the ID token.
• Storing tokens in localStorage. An XSS steals them. Use an HttpOnly cookie or a server-side intermediary.
• Trusting a JWT without verifying the signature, exp, iss and aud, or letting the token choose the algorithm.
• Putting personal data inside the JWT. It is signed, not encrypted: anyone can read it.
• Accepting tenant_id as a client parameter. It is an IDOR by another name.
• Granting permanent privileged access because "it is more convenient". The normal state of an administrative account should be without privileges.
• Recertifying with the rule "we withdraw what somebody asks us to withdraw". By default, what is not confirmed must be withdrawn.

Tips:

• Start with what pays best: FIDO2 on the administrative accounts and an expiry on every token. Two afternoons of work that close the two most exploited vectors.
• Write out the leaver checklist from section 2.3 and run it on the last day, not afterwards. Keep signed evidence.
• Separate the administrative account from the personal one for Lucía and Marta. It is inconvenient for a week and it protects for years.
• Put the roles.yaml file in the repository and treat it as code: review, history and controlled deployment.
• Add the tenant isolation test to CI. Five lines that permanently guard against the most expensive failure a SaaS can have.
• Run the non-expiring token query today. If it returns rows, you already have this week's task.
• At recertification, always sort by date of last use: it turns a tedious review into one-second decisions.

Iván leaves Nimbus. Lucía does the following:

1. Deactivates his mail account.
2. Removes him from the internal messaging channel.
3. Recovers the laptop.
4. Removes him from the GitHub repository as a collaborator.

Two months later, during the quarterly review, activity is spotted: somebody has run a deployment at 4:10 in the morning.

Required: (a) list at least six accesses that are probably still alive and explain why each is dangerous; (b) write the complete leaver checklist that should have been applied; (c) explain how a deployment could have been run if the GitHub account had been removed, with two different technical hypotheses; (d) propose three structural measures that reduce this risk regardless of the discipline of whoever runs the offboarding.

This is the authentication code of a new version of the Nimbus API:

Required: (a) identify all the security problems, classifying them as critical, high and medium; (b) explain the concrete impact of the two most serious ones on the clinics' data; (c) rewrite issuance and validation correctly; (d) explain what changes if the API is deployed on three instances and a session has to be revoked immediately.

Nimbus is launching occupancy reports by practitioner. Business requirements:

• The centre administrator sees the report for every practitioner in their centre.
• The practitioner sees only their own report.
• Reception does not get access to this feature.
• Nimbus support (Rubén) can see a centre's report only with an open ticket and the approval of a second operator, for 30 minutes at most, and the centre must be notified.
• Reports can be exported to CSV, with a maximum of 5,000 rows and 6 requests per hour per user.
• A practitioner who left more than 90 days ago must not appear.

Required: (a) decide which authorisation model or combination of models you would use and justify it; (b) write the corresponding fragment of roles.yaml; (c) write the Python code for the endpoint with all the authorisation checks, stating in comments which attack each one prevents; (d) give three events you would log and one alert you would build on them.

Solution 1

(a) Accesses that are probably still alive:

(b) The checklist from section 2.3, carried out on the last day, with signed evidence and with reassignment of ownership of his inventory assets.

(c) Two hypotheses for the night-time deployment:

1. A live personal token. Iván created a GitHub token with write permissions and no expiry — the pattern of the 01-04 finding. Removing the account as a collaborator does not invalidate the token, which keeps authenticating against the service's API. This is the most likely hypothesis.
2. An SSH key or infrastructure credential. The deployment did not go through GitHub: it was run directly against the server with an SSH key left in authorized_keys, or with cloud provider credentials he knew.

In both cases, the lesson is the same: an identity is not just the account. It is the account plus every artefact it created, each of which lives independently.

(d) Three structural measures:

1. Federate as much as possible with the identity provider, so that a single offboarding deactivates the maximum number of accesses. It reduces dependence on human discipline.
2. Forbid by policy non-expiring tokens and personal SSH keys on servers, replacing them with short-lived credentials issued by CI and bastion access with a central identity. An artefact that does not exist cannot be forgotten.
3. Quarterly recertification with the query from section 11, which catches whatever escaped the process. It is the safety net: it assumes the offboarding will fail at some point and limits how long it takes to notice.

Solution 2

(a) Problems found:

(b) Impact of the two most serious. With none accepted, an attacker builds a token with "tenant_id": 7 and "roles": ["centre_admin"], unsigned, and the API accepts it. Result: full access to the diary and the data of any clinic, with no credentials needed, no phishing and nothing else exploited. Combined with the absence of expiry, a token obtained just once — from a log, from a screenshot, from a laptop — gives indefinite access. In terms of the CIA triad, this is a total loss of confidentiality and integrity over data that reveals health information, and it triggers notification obligations (06-03).

(c) Correct code:

(d) Immediate revocation with three instances. A JWT is self-contained: the three instances validate it without consulting anyone, so a leaver has no effect until it expires. Solutions, which can be combined:

1. A shared revocation list (Redis) consulted by jti, with the same lifetime as the token: at most 15 minutes' worth of entries. Cost: one fast lookup per request; it is what the code above does.
2. A short access token life (5-15 min) with a rotating refresh. The real revocation is applied to the refresh, which is checked against the database: the maximum exposure window is the access token's lifetime.
3. A per-user invalidation marker (tokens_valid_from): any token with an iat earlier than that marker is rejected. It revokes all of a person's sessions with a single field, ideal for a leaver or a compromise.

The underlying trade-off: the JWT is fast and stateless, but revocation requires state. The practical solution is not to pick one extreme, but to shorten the token's life so that the window is acceptable and keep a revocation mechanism for the urgent cases.

Solution 3

(a) Model chosen: RBAC as the base + ABAC/ReBAC for scope and conditions. Justification:

• The three profiles (centre administrator, practitioner, reception) are roles: RBAC expresses them directly and auditably.
• "Only their own report" is not a role: it is a relationship between the user and the resource (the assigned practitioner). It requires ReBAC or an attribute.
• "With a ticket, approval, 30 minutes and notification" are contextual conditions: ABAC.
• "A practitioner who left more than 90 days ago" is a temporal attribute of the resource.

Pure RBAC would force a role to be created per practitioner, which is ungovernable. Pure ABAC would be expressive but very hard to audit. The hybrid is what real systems use.

(b) Fragment of roles.yaml:

(c) Endpoint with the checks:

(d) Three events to log and one alert:

Alert: support access to more than 3 distinct tenants in 24 hours, or any support access with no associated ticket. It is exactly the signal that would have caught the support panel incident from the 02-02 exercise in hours instead of three days, and it is cheap to build because the fields are already in the log. A second useful alert: any CSV export outside the tenant's working hours, which takes advantage of the fact that Nimbus knows each centre's opening times.

You have worked through the domain that decides most incidents today. You know why identity is the new perimeter: none of Nimbus's relevant assets sits behind a network boundary, and the only thing that crosses every context is who you are. You have separated identification, authentication and authorisation precisely, and you have settled the trap that recurs throughout the course: most serious incidents are not authentication failures but authorisation failures. You have worked through the identity life cycle and its weak point, the leaving process, with the concrete case of the eight accesses that survive a mail deactivation, the checklist that prevents it and the two things that are always forgotten: revoking sessions and tokens, and rotating the shared secrets.

In passwords you take away the updated guidance — length over complexity, no forced expiry, allow pasting, and the most effective and least implemented measure: checking against leaked lists — and the definitive argument in favour of managers. In MFA you have learned the hierarchy that really matters, the one of phishing resistance, and the reason FIDO2 is qualitatively different: the key never leaves the device and the signature is bound to the domain, so that the defence works even if the user notices nothing. You have seen the inner workings of TOTP verification with its four decisions — a bounded window, constant-time comparison, single-use consumption and an encrypted secret — and the fix for MFA fatigue with number matching.

In federation you have settled the exact difference between OAuth 2.0, which authorises, and OpenID Connect, which authenticates, together with the Authorization Code + PKCE flow and the reason PKCE is essential in public applications. In sessions and tokens you have worked through the cookie attributes that neutralise XSS, CSRF and capture in transit, and you have compared a naive JWT validation with a correct one: signature verified with the issuer's key, the algorithm fixed by us, iss, aud and exp checked, revocation by jti and sensitive permissions reloaded from the source of truth. And you have fixed the non-expiring token of 01-04, the first link of the chained attack of 02-02.

In authorisation you have compared DAC, MAC, RBAC, ABAC and ReBAC and you have built Nimbus's real design: customer roles and internal roles in a versioned roles.yaml, with impersonate_user as a conditioned, notified permission, and audit:delete denied to everybody. You have closed off multi-tenant isolation with its golden rule — the tenant_id always comes from the token, never from the client — and its automated test in CI. And you have finished with privileged accounts: separating the administrative account, PAM and the just-in-time access that turns least privilege into least duration, the target configuration for the consultancy's access (A-19) and the periodic recertification whose decisive rule is that what is not confirmed is withdrawn.

You now have the module's complete armoury: you know what gets attacked, how, what defends against it and how access is controlled. What is missing is the reality check. In the module's final lesson, Cybersecurity Incident Case Studies (02-06), we will apply a method of analysis to real, public incidents — Target, WannaCry, Equifax, SolarWinds, Colonial Pipeline and a leak through misconfigured cloud storage — map each one to the concepts of the course, extract the patterns that recur without exception, and reconstruct hour by hour a fictitious ransomware incident at Nimbus that comes in through the consultancy's remote access, in order to answer the only question that matters: what would have changed the outcome.