Royal Army College

Lesson Overview

Take almost any serious compromise of a digital organisation, anywhere, and trace it back to its root. Far more often than not, you will not find a clever break-in through a wall of code. You will find an account: a password that was stolen, a login that was shared between two people, an old account that nobody ever switched off. The wall was never breached. Someone simply walked through the door with a key that should not have been in their hand. This is the plain and slightly uncomfortable truth that this whole course is built on, and it is why CIS 220 begins not with firewalls or malware but with identity. In a state held together by information, identity is the master key, and whoever holds the key holds the door.

This first lesson of CIS 220 sets the scene for the speciality of identity, access, and records security. It deepens the identity and access material you first met in CIS 210 and turns it into a discipline. It explains why identity is the control plane of a digital Principality, the layer through which nearly all access is decided, and why protecting identity protects almost everything else. It looks hard at the single sign-on, the identity service that is both a great convenience and a great concentration of risk, and why it must be guarded above all else. It draws the clean and important distinction between authentication (proving who you are) and authorisation (what you are allowed to do once you are in), which are two different problems that people constantly confuse. And it lays out a map of the discipline this course teaches, so that every lesson that follows has a place to sit.

This is the knowledge layer. Reading about strong authentication does not enrol a passkey for you, and reading about deprovisioning does not switch off a single forgotten account, any more than reading about a backup restores a file. The real habits of this speciality, configuring multi-factor authentication on an account, running and testing a backup of a register, walking through a reporting drill when something looks wrong, are practised and signed off in person where supervision allows, on the real systems you are entrusted with and under the eye of someone responsible for them. By the end you will be able to explain why identity is the control plane of a digital state and why protecting it protects almost everything; describe why the single sign-on and identity service is the master key that must be guarded above all, with its convenience and its concentration of risk; distinguish clearly between authentication and authorisation and give an example of each; and outline the five strands of the discipline this course teaches, namely the account lifecycle, least privilege, secrets, records, and audit.

Key Terms

Identity: the digital representation of a person (or a system) that our services recognise, usually an account, against which we decide who someone is and what they may do. Protecting identity is the heart of this speciality.
Control plane: the layer that decides and grants access across many systems at once, as opposed to the data itself. In a digital state the identity service is the control plane: bend it and you bend almost everything downstream.
Single sign-on (SSO): one identity service that lets a person sign in once and then reach many connected services without logging in again. A great convenience, and a great concentration of risk in one place.
Identity service / identity provider: the system that holds accounts and proves who someone is to all the other services. The Principality runs one. It is the master key, and it is guarded above all.
Authentication: proving who you are. A password establishes a claim; multi-factor authentication strengthens the proof. Authentication answers the question, "are you really this person?"
Authorisation: deciding what you are allowed to do once you have been authenticated. Authorisation answers a different question, "now that we know who you are, what may you touch?"
Credential: the thing you present to prove identity, a password, a one-time code, a passkey, a per-user certificate or key. A stolen credential is a stolen identity.
Least privilege: the rule that an account is given only the access its role actually needs, and no more. A pillar of authorisation, taught in full in Lesson 03.
Account lifecycle: the whole life of an account, from being created (joiner), through changes of role (mover), to being switched off when a person leaves (leaver). Taught in Lesson 02.
Audit trail: the protected record of who accessed or changed what, kept so that misuse can be seen and accountability is possible. Taught in Lesson 10.
Access follows appointment, not qualification: the governing rule of the whole specialities framework. Completing this course grants you no access to anything; access to a real system is granted by the authority responsible for it, and only when your appointment needs it.

Identity is the control plane

It is worth being exact about what "control plane" means, because the phrase carries the whole argument of this lesson. In any system there is the data (the register of nationals, a roster, a record of decisions) and there is the layer that decides who may reach that data. The second layer is the control plane. It does not hold the information itself; it holds the power to grant or refuse access to it. In a digital Principality, that control plane is identity. Nearly every door into nearly every system is opened by first proving an identity and then checking what that identity is allowed to do. Reach the identity layer and you do not need to attack each system one by one. You let yourself in everywhere the identity is trusted.

This is why protecting identity protects almost everything else, and it is not an exaggeration to put it that strongly. Consider what an attacker actually has to do to harm us. They could try to break each service individually, defeating its patching, its configuration, its monitoring, one hard target at a time. Or they could obtain one valid set of credentials and simply log in as a trusted person, after which most of the work is already done for them. Faced with that choice, attackers overwhelmingly take the second path, because it is far easier and far quieter. The result, seen again and again across the whole field, is that the great majority of serious compromises come down to credentials that were stolen, shared, or never removed. The lock was sound. The key was the problem.

For the Principality this lands with particular force. We have already learned, in CIS 201, that a non-territorial digital state lives in its records and its services rather than on a patch of ground, and that its accounts and keys are how the right people reach the right systems. Put those two ideas together and the conclusion is direct: if identity is how access to the whole state is decided, then identity is the single most valuable thing an attacker can take and the single most important thing we defend. A taken-over identity does not just expose one file. To the systems that trust it, the attacker becomes that person, with that person's reach. This is the precise reason the course is named as it is, and why it opens here rather than anywhere else.

        IDENTITY AS THE CONTROL PLANE
   one layer decides access to everything below it

                  +----------------------+
                  |   IDENTITY SERVICE    |   <-- the control plane
                  |  (who you are + what  |       guard this above all
                  |   you are allowed to) |
                  +----------+-----------+
                             |
        +----------+---------+---------+----------+
        |          |         |         |          |
        v          v         v         v          v
   +---------+ +-------+ +--------+ +-------+ +---------+
   |Register | |Roster | |Records | | Mail  | | Maps /  |
   |of       | |&      | |&       | |&      | | TAK &   |
   |nationals| |duties | |decrees | |comms  | | certs   |
   +---------+ +-------+ +--------+ +-------+ +---------+

   Reach the top box and you do not attack each service below.
   You are simply trusted everywhere. That is why identity is
   the master key, and why one taken-over account can do so much.

The single sign-on: the master key, and its two faces

Most of what has been said so far is true of identity in general. It becomes sharper still when a state, sensibly, adopts a single sign-on. The Principality runs an identity service through which a member signs in once and is then recognised across many connected systems without logging in separately to each one. This is the right design for a small force, and you should understand clearly why before you understand its danger, because the two are inseparable.

The convenience is real and it is not merely comfort. One identity service means one place to create an account and one place to switch it off, so that when a person leaves, a single action can close every door at once rather than leaving a trail of forgotten logins scattered across a dozen systems. It means multi-factor authentication can be required in one place and enforced everywhere downstream. It means access can be reviewed in one place instead of being chased through every service separately. A single front door, well guarded, is genuinely easier to defend than twenty side doors that each have their own neglected lock. For an organisation with limited expertise, that consolidation is a security gain, not just a tidiness one.

But the same property that makes the single sign-on convenient makes it dangerous, and an honest member must hold both thoughts at once. Convenience and risk here are two faces of one coin: a single sign-on concentrates access, and so it concentrates risk. The very fact that one key opens every door means that compromising that one key compromises every door. If an attacker takes over the identity service itself, or takes over a privileged account within it, they do not gain one system; they gain the power to become anyone and reach anything the service governs. This is why the identity service is guarded above all else in the whole estate, with the strongest authentication, the tightest control over who may administer it, the closest monitoring of its use, and the most careful protection of the secrets and keys behind it. It is the master key, and a master key is exactly the thing you protect most fiercely, precisely because it opens the most.

None of this is an argument against single sign-on. It is an argument for treating it with the seriousness its concentration demands. Throughout this course, when you meet a safeguard that feels heavier than a single ordinary account would seem to warrant, the reason is usually that the safeguard is really protecting the master key behind that account.

Authentication and authorisation: two different problems

There is a confusion so common, and so quietly costly, that it is worth stopping to clear it up before anything else in the course is built on top of it. People say "access" as if it were one thing. It is two things, and they are different problems with different answers. The two words are authentication and authorisation, and the discipline of this course depends on keeping them straight.

Authentication is proving who you are. When you present a password, then a one-time code from an authenticator app, then perhaps a fingerprint, you are answering a single question: are you really the person this account belongs to? That is all authentication does. It establishes identity to some degree of confidence. A password alone is a weak proof, because a password can be stolen, guessed, or reused from some other breached site. Combining factors, something you know, something you have, and something you are, makes the proof much stronger, which is the whole point of multi-factor authentication. But however strong it becomes, authentication answers only the first question. It says who you are. It says nothing whatever about what you may then do.

Authorisation is the second, separate question: now that we are confident who you are, what are you allowed to do? This is about permissions, roles, and limits. Two people can both authenticate perfectly, proving beyond doubt who they are, and still be allowed to do entirely different things once inside, because their roles differ. A member authorised to read a roster is not thereby authorised to edit the register of nationals, even though both authenticated with the same strength. Authorisation is where least privilege, need to know, and role-based access all live, and it is the subject of Lesson 03.

The reason this distinction is not pedantry is that the two failures look nothing alike and are defended in different ways. A failure of authentication is an impostor getting in as someone they are not, defended by strong, phishing-resistant proof of identity. A failure of authorisation is a genuine, correctly identified person being allowed to do far more than their role should permit, defended by careful, least-privilege permissions and regular review. A system can be excellent at one and dangerously poor at the other. Strong MFA on an account that is authorised to touch everything is still a serious risk. The discipline is to get both right.

   AUTHENTICATION vs AUTHORISATION  (two different questions)

   AUTHENTICATION                 |  AUTHORISATION
   "ARE YOU REALLY THIS PERSON?"  |  "WHAT MAY YOU DO NOW?"
   ------------------------------ | ------------------------------
   proves WHO you are             |  decides WHAT you may touch
   password + a code + a face     |  roles, permissions, limits
   factors: know / have / are     |  least privilege, need to know
   strengthened by MFA, passkeys  |  governed by RBAC, review
   fails as: an IMPOSTOR gets in  |  fails as: a real person can
   as someone they are not        |  do far MORE than their role
                                  |  should ever allow
   ------------------------------ | ------------------------------
   Lesson: prove identity well    |  Lesson 03: grant access well

   You must get BOTH right. Perfect proof of identity on an account
   allowed to touch everything is still a serious risk.

A small worked contrast fixes the idea. A member signs in to a service. The single sign-on checks their password and a code from their authenticator app and is satisfied that they are who they claim: that is authentication, and it has succeeded. The service then checks what that member's role permits and shows them the roster they maintain, but not the personal records of nationals, which their appointment does not cover: that is authorisation, doing its separate job. Both worked. Both were needed. Neither one alone is "access".

The map of the discipline this course teaches

If identity is the master key, then guarding it well is not one task but several, and it helps to see the whole shape before learning each part. The rest of CIS 220 is organised into five strands, and every later lesson is one of them. Hold this map in mind and nothing in the course will feel like loose advice; each piece will have a place.

The first strand is the account lifecycle: the orderly creation, change, and removal of accounts over their whole life. Accounts are born when a person joins, change when a person moves role, and must die promptly when a person leaves. The forgotten account that nobody switched off, and the orphaned account with no clear owner, are among the commonest ways in anywhere. Lesson 02 teaches the joiner, mover, leaver discipline and the access reviews that keep the population of accounts honest.

The second strand is least privilege and authorisation done well: granting each account only what its role genuinely needs, by role rather than person by person, with sensitive processes split so no single person controls them end to end, and with privileged admin access kept separate and granted sparingly. This is the second of the two problems named above, and Lesson 03 is devoted to it.

The third strand is secrets, keys, and credentials: the passwords, the API tokens, the certificates, and the private keys (the per-user TAK .p12 is a familiar example) that actually unlock systems. These are guarded like the keys they are, never hardcoded into programs or shared over chat, kept in a proper vault, rotated on a schedule, and revoked the instant they are lost or a holder departs. Lesson 04 covers this.

The fourth strand is records and data security: protecting the registers of the state and, above all, the identities and personal data of nationals. This means classifying data by sensitivity, encrypting it at rest as well as in transit, keeping it only as long as there is a lawful need, and honouring the principles of data protection so that nationals' privacy is the default. Lesson 05 covers this.

The fifth strand is audit, review, and accountability: logging who accessed or changed what, protecting those logs from tampering, and reviewing them, so that misuse becomes visible and people can be held to account. It is also where the framework's governing rule formally lives: access follows appointment, not qualification, and is revoked when the appointment ends. Lesson 10 covers this.

   THE FIVE STRANDS OF CIS 220  (the discipline of the master key)

   L02  ACCOUNT LIFECYCLE ....... create, change, REMOVE accounts
                                   (joiner / mover / leaver, reviews)
   L03  LEAST PRIVILEGE ......... grant only what the role needs
                                   (RBAC, separation of duties, admin)
   L04  SECRETS & KEYS .......... guard passwords, tokens, certs, keys
                                   (vault, rotate, revoke, never share)
   L05  RECORDS & DATA .......... protect registers & nationals' data
                                   (classify, encrypt, retain, privacy)
   L06  AUDIT & ACCOUNTABILITY .. log, protect, review who did what
                                   (audit trails; access = appointment)

        all five guard the same thing -> IDENTITY, the master key

These five are not separate subjects that happen to share a course. They are five sides of one task: keeping the master key, and everything it opens, in the right hands and out of the wrong ones. The lifecycle decides who has a key at all. Least privilege decides how many doors each key opens. Secrets management protects the keys themselves. Records security protects what lies behind the most sensitive doors. Audit lets us see, afterwards, who used which key for what. Remove any one of the five and the others are weakened.

In Practice: a systems assistant traces a real problem

Corporal Imani is a systems assistant in a small section and holds an appointment that includes helping to administer one of the Principality's self-hosted services. Note the wording: her access comes from her appointment, not from any certificate she has earned, and it is limited to what that appointment needs. During a routine access review, which she has learned to take seriously, she notices an account on the service that still works but that she cannot match to any current member. It authenticates fine. Its password is valid. By every test of authentication, it is a real, working identity.

A week earlier, Imani might have shrugged. Today she sees it for what it is. This is an orphaned account, very likely a leaver whose access was never removed, and it is exactly the kind of forgotten, never-removed credential that the whole field warns is among the commonest ways in. Its authentication being sound is not reassuring; it is the danger. The account proves "who you are" perfectly well, to whoever now holds its password. The real question is authorisation: what is this ownerless key still allowed to touch? She checks and finds it carries more access than even a current holder in that old role would now need, a small example of how privilege quietly accumulates and is never trimmed.

Imani does not start changing things on her own initiative. She is defensive and lawful, she preserves rather than tampers, and she reports the finding to the authority responsible for the service so that the account can be deprovisioned properly and the access review widened to look for others like it. She also notes, correctly, that because this service sits behind the single sign-on, the right long-term fix is to ensure leavers are switched off at the identity service itself, where one action closes every door at once. She has done nothing clever. She has understood that identity is the control plane, that an orphaned account is a master key lying in the open, and that the answer is the plain discipline this course exists to make ordinary.

Check Your Understanding

Explain in your own words what it means to say that identity is the "control plane" of a digital state, and why protecting identity protects almost everything else. Refer to the idea that most serious compromises come down to stolen, shared, or never-removed credentials.
The single sign-on is described as having "two faces". State the convenience it offers and the concentration of risk it creates, and explain why both come from the same property of having one identity service.
Distinguish authentication from authorisation. For each, give one example from this lesson, and describe what a failure of each one looks like and why getting only one of the two right is not enough.

Reflection (write a short paragraph): Think about an account you personally use on Army business that signs you in to several services at once. If that one set of credentials were taken over, how far would the harm reach, and what does that tell you about how heavily that single login deserves to be protected compared with an ordinary, isolated account?

Summary

Identity is the control plane of a digital state: the layer through which access to nearly every system is decided. The great majority of serious compromises come down to credentials that were stolen, shared, or never removed, so protecting identity protects almost everything else.
The single sign-on / identity service is the master key and must be guarded above all. Its convenience (one place to create, enforce MFA, review, and switch off accounts) and its risk (one key opens every door) are two faces of the same concentration.
Authentication proves who you are (password plus MFA); authorisation decides what you may do once in (roles, least privilege, need to know). They are different problems with different failures, and both must be got right; perfect proof of identity on an over-privileged account is still a serious risk.
This course teaches the discipline of guarding the master key in five strands, deepened across the lessons that follow: the account lifecycle (Lesson 02); least privilege and authorisation (Lesson 03), extended by privileged access management (Lesson 06) and federation and single sign-on (Lesson 07); secrets and keys (Lesson 04); records and data security (Lesson 05), extended by data classification and the data lifecycle (Lesson 08) and data protection and the privacy of nationals (Lesson 09); and audit and accountability (Lesson 10).
The speciality is defensive and lawful only, and the governing rule runs through all of it: access follows appointment, not qualification, and is revoked promptly when the appointment ends. Completing this course grants no access to anything.
This lesson opens CIS 220 and deepens the identity and access material introduced in CIS 210. It is the natural partner of SIG 220 · Communications Security and Digital Discipline, supports PME 210 · Basic Staff Duties and Written Orders (custody of records), draws on HCR 220 · Emergency Preparedness and Civil Resilience (continuity), and leads on to CIS 310 · Cyber Incident Response and Continuity.

Identity as the Master Key