Royal Army College

Lesson Overview

The lessons before this one built the frame of identity and access: identity as the master key of a digital state, the joiner-mover-leaver lifecycle that creates and removes accounts, and the authorisation rules of least privilege, role-based access, and separation of duties that decide what an account may do. All of that machinery rests on a smaller, quieter thing: the secret. A password, an API token, a certificate, a private key such as the per-user TAK .p12, these are the objects that actually unlock the systems and prove identity to them. Grant the cleanest access you like; if the secret that authenticates an account leaks, the access goes with it. This lesson is about guarding those secrets, because they are the keys to every door the earlier lessons so carefully fitted.

A secret is exactly what the word says: something whose protective power depends on its being known to as few people as possible. The moment a secret is shared too widely, written into code, pasted into a chat, or left on a lost device, it stops doing its job, because the thing that made it safe was that almost no one had it. So this lesson teaches the handling that keeps a secret a secret: never hardcoding it into code or sending it over chat or email; storing it in a secrets manager or vault rather than scattering copies; rotating it on a schedule and at once when a person leaves; and revoking it immediately if it is lost or leaked. It gives special attention to the secrets that have no human to watch over them, the service accounts and machine keys that run quietly in the background and are forgotten precisely because they never complain.

This is the knowledge layer. Reading it well prepares you, but it does not by itself protect a single key. The practical parts, storing a real secret in a vault, rotating a token, walking through the revocation of a compromised certificate, and standing up a service account correctly, are done and signed off in person, on the systems the Army actually uses, where supervision allows. By the end you will be able to name the kinds of secret a digital state depends on and explain why each is treated as a key; state and apply the rules that secrets are never hardcoded or shared over chat or email but kept in a vault; rotate secrets on a schedule and immediately on a person's departure, and revoke a lost or leaked secret at once; explain why a secret known to too many people is no longer a secret; and give the special care that service accounts and machine keys need.

Key Terms

Secret: any piece of information that unlocks a system or proves an identity to it and must therefore be kept to as few people as possible: a password, an API token or key, a certificate, a private key. Secrets are guarded like keys, because that is what they are.
Credential: anything an account presents to prove who it is and gain access: a password, a one-time code, a token, a certificate, a key. Every credential is a secret or contains one.
API token (or key): a string that lets one program or service authenticate to another without a person typing a password; it acts on behalf of whoever holds it, so it is as powerful as the access it grants and must be guarded like a password.
Certificate: a cryptographic credential that proves an identity to a system, in the Army's case the per-user TAK .p12 that proves a device to the server; it pairs with a private key and is protected like one.
Private key: the secret half of a cryptographic key pair; the part that must never be shared, because whoever holds it can act as the identity it represents. The public half may be shared freely; the private half never.
Hardcoding: writing a secret directly into the text of a program's source code or configuration, where it is then copied, shared, and stored everywhere the code goes. A cardinal mistake, because the secret can no longer be controlled.
Secrets manager (vault): a trusted system built to store secrets encrypted, hand them out only to the accounts and programs that need them, and record who took what. The proper home for a secret, in place of scattered copies.
Rotation: replacing a secret with a fresh one on a planned schedule and at trigger events, so that any old copy that has quietly leaked stops being useful, and so that a compromise has a limited life.
Revocation: cancelling a secret, a token, a certificate, a key, so that it no longer unlocks anything, even in the hands of whoever holds the copy. The standing remedy the instant a secret is lost or leaked.
Service account: an account used by a program or a system rather than a person, to run automated tasks; it holds powerful secrets, has no human watching over it day to day, and so needs deliberate, owned care.
Machine key: a secret held by a device or a service to authenticate itself automatically, with no person in the loop at the moment it is used; like a service account's credential, it must be inventoried, owned, and rotated.

What a secret is, and why we guard it like a key

Begin with the family, because the rules that follow apply to all of it. A secret is anything that, when presented, unlocks a system or proves who an account is. The plainest example is a password, the thing a person types to sign in. But a digital state runs on far more than passwords, and most of its secrets are never typed by anyone. An API token is a string that lets one program speak to another as a trusted caller, so that the Army's own services can read and write to each other without a human in the loop; whoever holds that token can do whatever it permits, which makes it exactly as powerful as a password and often more so. A certificate, such as the per-user TAK .p12, proves a device's identity to a server and admits it to the net. A private key is the secret half of a cryptographic pair, the part that must never leave its owner, because anyone who holds it can act as the identity it stands for. Different shapes, one nature: each is a key, and each unlocks a door.

That is why a single rule of mind governs the whole lesson, and it is worth stating before any of the specific handling. A secret is only as safe as it is secret. Its protective power comes entirely from the fact that almost no one has it. A lock is strong because the key is rare; the strongest lock in the world is open to anyone holding a copy of the key. So everything below, the storing, the not-sharing, the rotating, the revoking, is in service of one aim: keeping the number of copies, and the number of people and places that hold them, as small as it can possibly be. Treat every secret you handle as you would treat the physical key to a secure store, because in a digitally organised state it is precisely that, and there is no perimeter fence behind it to catch a key that gets loose.

This lesson sits directly on top of two you have already met. CIS 201, in its lessons on passwords and on devices, taught the personal side of this, strong unique passwords held in a manager, and the protection of certificates like the TAK .p12 on the device that holds them. SIG 220 · Communications Security and Digital Discipline taught the same disciplined mindset for the bearers that carry the Army's traffic, where the rule was that encryption protects the message but cannot protect a key left under the mat. This lesson takes that mindset and applies it to secrets as a class, across people, programs, and machines, at the scale of a state's systems rather than a single device.

   THE SECRETS FAMILY  (different shapes, one nature: each is a KEY)

   PASSWORD        a person types it to sign in
   API TOKEN/KEY   a program presents it to call another service as a
                   trusted caller; as powerful as the access it grants
   CERTIFICATE     proves an identity to a system
                   (e.g. the per-user TAK .p12)
   PRIVATE KEY     the secret half of a key pair; whoever holds it can
                   ACT AS that identity. Public half: share freely.
                                                  Private half: NEVER.

   One rule of mind over all of them:
   A SECRET IS ONLY AS SAFE AS IT IS SECRET.
   Its power comes from how FEW people and places hold it.
   Guard each like the physical key to a secure store, because it is.

A secret known to too many people is no longer a secret

The single idea most worth carrying out of this lesson is this: a secret shared too widely has already failed, whether or not anything bad has happened yet. People tend to think of a leak as a dramatic event, a theft, a breach. Far more often it is quiet and ordinary. A password is shared with a colleague "just this once". A token is pasted into a team chat so everyone can use it. A certificate is emailed to three people because it was quicker than the proper channel. None felt like a breach at the time; each one was, because the secret is now held by more people, in more places, than anyone is tracking, and from that moment no one can honestly say who has it.

The harm is twofold. First, every extra holder is another person who can be phished, whose device can be lost, whose carelessness can leak the secret onward, so the chance of exposure grows with every copy. Second, and worse for accountability, a secret held by many cannot be tied to anyone. If five people know the password to a shared account and that account does something it should not, no one can say which of the five did it, and the audit trail, the very thing the next lesson is built on, becomes worthless. This is one of the deepest reasons the earlier lessons insisted on individual accounts rather than shared logins: a secret is meant to belong to exactly one identity, human or machine, and to be presented by that identity alone.

So the working test is simple and strict. Before a secret reaches another person or place, ask: does this party actually need it to do a defined job, and is this the proper channel for it to travel? If the honest answer is no, the secret does not go. "It would be convenient" is never a reason to widen a secret, because convenience for the holder is convenience for the attacker too. When a secret genuinely must be used by more than one party, the right answer is almost never to copy it more widely; it is to issue each party its own secret, so that each can be tracked, rotated, and revoked on its own, and the loss of one does not compromise the rest.

Never hardcode, never send over chat or email: store it in a vault

Two handling rules follow directly, and they are absolute. The first concerns where a secret must never live; the second concerns where it must.

Never hardcode a secret into code. Hardcoding means writing a password, a token, or a key directly into the text of a program or its configuration files. It is tempting because it is the quickest way to make a thing work, and it is one of the most common and most damaging mistakes in the whole field. The reason is that source code does not stay still: it is copied to every developer's machine, stored in version-control history, pushed to repositories, included in backups, and shared with anyone who touches the project. A secret written into code is therefore copied, automatically and invisibly, to all of those places, and once it is in a repository's history it is extraordinarily hard to remove, because the old versions remain. The Principality has felt this in earnest: a real incident turned on a long-lived secret left where it could be read, and putting it right cost the rotation of token after token across the estate. So the rule is plain: secrets do not go in code. The code refers to a secret by name and fetches it at run time from a proper store; the secret itself lives elsewhere.

Never send a secret over chat or email. Email and chat are convenient, persistent, widely copied, and weakly controlled. A secret pasted into a chat is now in that chat's history, on every member's device, in the service's storage, and in any export of the conversation, long after the moment that needed it has passed. A secret emailed is in the sender's sent folder, the recipient's inbox, both mail servers, and any forward. None of these is a place you can later clean reliably, and any can be reached by an attacker who compromises one account along the way. The rule admits no "just this once": if a secret must move between parties, it moves by the proper secure channel the Army provides for exactly that purpose, never by the general-purpose tools used for ordinary conversation.

The positive form of both rules is the same: store secrets in a secrets manager, a vault. A secrets manager is a system built for this one job. It holds secrets encrypted at rest; it hands a secret out only to the specific account or program that is entitled to it, and only when needed; and it records who or what took each secret, so that access leaves a trail. Programs are given the means to fetch their secrets from the vault at run time instead of carrying them in their code. People who genuinely need a secret retrieve it from the vault under their own identity rather than receiving a loose copy. The gain is decisive: instead of an unknown number of scattered copies that can never be counted or recalled, there is one controlled home, from which a secret can be rotated or revoked in a single place and the change take effect everywhere. The Principality keeps its own secrets this way, in dedicated stores rather than loose in code or configuration, for exactly these reasons.

   DO  /  DON'T  WITH A SECRET

   DON'T                              DO
   -----------------------------      ------------------------------------
   write it into source code or       refer to it by name; fetch it at
   a config file (hardcode)           run time from the VAULT

   paste it into a team chat          retrieve it yourself from the vault
   so "everyone can use it"           under your own identity

   email it / forward it              move it only by the proper secure
                                      channel provided for the purpose

   keep extra copies "in case"        keep ONE controlled home; rotate /
   on drives, notes, spares           revoke there and it changes for all

   share one secret among many        issue each party its OWN secret, so
   people or services                 each is tracked, rotated, revoked

   keep it for ever, unchanged        ROTATE on a schedule and on triggers

   Guiding test before a secret moves: does THIS party need it for a
   defined job, and is THIS the proper channel? If not, it does not go.

Rotation: change secrets on a schedule and on triggers

Storing a secret well is not the end of its care, because even a well-kept secret can leak in ways no one notices, and a secret that never changes gives any such leak unlimited life. Rotation is the practice of replacing a secret with a fresh one, both on a planned schedule and at certain trigger events, so that old copies, wherever they may have quietly ended up, stop working. Rotation does not assume a particular leak has happened; it assumes that over enough time some leak probably has, and it limits how long any leak can be useful. A rotated secret turns an open-ended exposure into a brief one.

There is an important distinction to hold here, because it differs from one of the rules CIS 201 taught for personal passwords. For an ordinary user's password, current guidance, which CIS 201 follows, is not to force routine periodic change, because forced rotation drives people to weak, predictable, lightly varied passwords, and to change a password only on evidence of compromise. That advice is about human-chosen, human-remembered passwords. The secrets in this lesson are mostly different: long machine-generated tokens, keys, and certificates that no person memorises, where the cost of rotating is borne by automation rather than by a tired human inventing a new word. For those, scheduled rotation is sound and expected, precisely because none of the reasons that make it harmful for human passwords apply. The principle is consistent once you see it: rotate where rotation costs nothing in strength and buys you a shorter window of exposure; do not rotate where forcing it would make the secret weaker. Match the rule to the kind of secret.

Two trigger events demand rotation at once, on top of any schedule. The first is a person's departure, or a change of role that removes their need for a secret. This ties straight back to the leaver and mover steps of the account lifecycle in Lesson 02. When someone leaves, deprovisioning their own account is only half the job; any shared secret they knew, a token they held, a service-account password they used, must also be rotated, because that knowledge walks out of the door with them and a deprovisioned personal account does nothing to recall a secret already memorised or copied. A mover who no longer needs a secret should, likewise, prompt its rotation so the old need cannot be quietly exploited. The second trigger is any suspicion of compromise, which the next section treats as its own urgent drill. Schedule plus triggers together is the working standard: change secrets regularly because some leak is always possible, and change them at once when a leak becomes likely.

Revocation: kill a lost or leaked secret immediately

Rotation limits exposure over time; revocation ends it now. To revoke a secret is to cancel it so that it no longer unlocks anything, even in the hands of whoever holds the copy. A revoked token is refused by the service it once opened; a revoked certificate is rejected by the server it once admitted; a revoked key opens nothing. Revocation is the standing, immediate answer to the worst case, the moment a secret is known or seriously suspected to be lost or leaked, and the governing rule is one word: at once.

The reason speed is everything is that a leaked secret is a live key in unknown hands, and every minute it remains valid is a minute it can be used. Unlike a stolen physical key, a leaked digital secret can be copied perfectly and used from anywhere in the world the instant it is taken, so there is no comfort in distance and no time to spare. This is the same logic, applied to secrets, that drove the lost-or-stolen-device drill in CIS 201 and SIG 220, where the worst thing about a lost device was rarely the hardware but the credentials and per-user certificate it held, and where the whole drill served one end: report fast so that access and certificates could be revoked. Revocation is what those drills were racing towards. A device lost and reported in minutes is a near miss precisely because the secret it carried can be revoked before anyone uses it.

What this asks of an ordinary member is therefore simple and unheroic. If you have any reason to think a secret has been exposed, a token pasted somewhere it should not have gone, a certificate sent to the wrong person, a key carried off on a lost device, a password you fear is known, report it at once to the person responsible for the system, plainly and in full, so it can be revoked. Do not delay out of embarrassment, do not try to quietly fix it yourself, and do not hope it will turn out fine; revocation is the responsible person's action, and they can only revoke what they know about, as fast as they hear about it. After revocation, a fresh secret is issued and the affected access restored, so that the result of honest, fast reporting is a changed lock and a contained incident. The result of a hidden or late-reported leak is a key left turning in the dark.

   SECRET LIFECYCLE:  ISSUE -> STORE -> USE -> ROTATE -> REVOKE

   ISSUE    create the secret; give it to ONE identity (person/machine)
             |    that actually needs it, for a defined job
             v
   STORE    put it in the VAULT, encrypted, access recorded;
             |   never in code, never in chat or email
             v
   USE      the entitled account/program fetches it at run time;
             |   no loose copies spread around
             v
   ROTATE   replace it on a SCHEDULE, and at TRIGGERS:
             |     - a person LEAVES or changes role
             |     - any SUSPICION of compromise
             v
   REVOKE   the instant it is LOST or LEAKED: cancel it NOW, so it
            opens nothing even in the holder's hands. Then re-issue.

   The whole point of a vaulted, single-home secret is that ROTATE and
   REVOKE happen in ONE place and take effect everywhere at once.

The special care of service accounts and machine keys

Most of what you have read assumed a person somewhere behind the secret, a member who notices a strange prompt, reports a lost phone, changes a password they fear is known. A great many of a digital state's secrets have no such person. A service account is an account used by a program or a system rather than a human, to run automated work: one service authenticating to another, a backup job reaching a database, a sync task talking to the identity service. A machine key is the secret such an account or device presents to prove itself, with no one in the loop at the moment it is used. These secrets are often the most powerful in the whole estate, because automation tends to be granted broad standing access so that it can run unattended, and they are at the same time the most easily forgotten, precisely because they never complain, never get locked out, and never call for help. A service account does its job silently for years, and silence is exactly how a neglected secret hides.

That combination, high power and low visibility, is why service accounts and machine keys need deliberate, named care rather than the ambient attention a human account receives. Three disciplines cover most of it. First, every service account and machine key has a human owner, a named person or appointment responsible for it, so it is never an orphan. The orphaned, ownerless account, you will recall from Lesson 02, is among the commonest ways in; a service account with no owner is an orphan that also holds power, and it must be found and either owned or removed. Second, least privilege applies to machines just as to people: a service account is given only the access its task needs, never broad standing power "to be safe," because an over-privileged automated account is a standing invitation no human is watching. Third, these secrets are inventoried, rotated, and revocable like any other, held in the vault, rotated on a schedule and when their owning person departs or their service is retired, and revoked at once if exposed. The hard part is simply remembering they exist, which is why the inventory and the named owner matter so much: you cannot rotate or revoke a secret you have forgotten you have.

One trap deserves naming, because it catches careful teams. When a person who set up a service leaves, their own account is deprovisioned cleanly, but the service account they created and its machine keys are easy to overlook, and they keep running with secrets that the departed person knew. This is the leaver problem of Lesson 02 reaching into the machine layer, and it is closed the same way: the leaver process must ask, every time, what service accounts and machine secrets this person owned or knew, and rotate or reassign them. A digital state stands or falls on these quiet credentials as much as on its members' passwords, and they deserve the same discipline, owned, least-privileged, inventoried, rotated, and revocable, applied with the extra deliberateness their silence demands.

In Practice: A Token in a Chat, Caught in Time

A systems assistant is helping a developer get a small internal tool talking to one of the Army's self-hosted services. Under time pressure, the developer pastes an API token straight into the team chat so the assistant can drop it into the tool and move on. It works, and for a moment everyone is pleased. Then the assistant, who has studied this lesson, feels the catch. That token is now in the chat history, on every member's device, in the service's storage, and in any export of the conversation, held by more people and in more places than anyone is tracking. By the test of this lesson it has already failed, whether or not anyone hostile ever sees it, because it is no longer a secret known to as few people as possible. It is a key lying on a table.

The assistant does not hide the mistake or quietly hope it is fine. They report it at once to the person responsible for the service, plainly: an API token for this service was pasted into team chat at such a time, treat it as exposed. The responsible person does the right thing in the right order. The token is revoked immediately, so that even though copies of it now sit in several chat histories, it opens nothing; a leaked key that no longer works is a harmless string of characters. A fresh token is then issued, and this time it is placed in the vault rather than passed around: the tool is configured to fetch it from the secrets manager at run time, by name, so the token itself never appears in the code, the chat, or anyone's notes. While they are at it, the responsible person checks that the new token carries only the access the tool actually needs, no broad standing power granted for convenience, applying least privilege to the machine just as it would apply to a person.

Look at what turned a slip into a non-event. The secret was understood for what it was, a key, so the instinct was revocation, fast and without drama, rather than embarrassment or delay. The fast, honest report gave the responsible person the chance to revoke before anyone could use the token, exactly as a fast report of a lost device lets a certificate be revoked before the device is unlocked. And the fix did not merely replace one loose copy with another; it moved the secret to its proper home in the vault and trimmed its privileges, so the same mistake could not be made the same way again. The token in the chat, caught in time, cost a few minutes and taught a lesson. The same token left sitting, unreported, could have cost a great deal more.

Check Your Understanding

Name the main kinds of secret a digital state depends on (give at least four, including the per-user TAK .p12), and explain why each is treated as a key. Then state in your own words why "a secret is only as safe as it is secret," and why a secret known to too many people is no longer a secret, referring both to the growing chance of exposure and to the loss of accountability.
State the two absolute handling rules (never hardcode a secret in code; never send it over chat or email) and explain why each of those places is so dangerous a home for a secret. Then explain what a secrets manager or vault is and the three things it does, and why storing a secret in one place lets it be rotated and revoked everywhere at once.
Distinguish rotation from revocation. For rotation, explain why scheduled rotation is right for machine tokens and keys even though CIS 201 says not to force routine change of human passwords, and name the two trigger events that demand rotation regardless of schedule. For revocation, explain why it must happen "at once" when a secret is lost or leaked, and tie this to the lost-or-stolen-device drill of CIS 201 and SIG 220. Finally, give the three disciplines that service accounts and machine keys need, and explain why their silence makes them easy to neglect.

Reflection (write a short paragraph): Think honestly about how secrets pass through your own hands and your team's habits. Has a password, token, or certificate ever been shared "just this once" over chat or email, or kept as an extra copy on a drive or in a note "in case it is needed"? Are the secrets you rely on stored in a proper vault, or scattered where no one could count the copies? If a token you held were exposed this evening, would you know who to report it to, and would you report it at once and in full rather than trying to quietly fix it? Consider too the quiet credentials, any service account or machine key in your corner of the Army's systems, and ask whether it has a named owner and only the access it needs. Choose one or two changes you could make this week to keep your secrets fewer, better stored, and quicker to revoke.

Summary

A secret is anything that unlocks a system or proves an identity to it: a password, an API token or key, a certificate, a private key such as the per-user TAK .p12. Different shapes, one nature, each is a key, and the governing rule of mind is that a secret is only as safe as it is secret, its power coming entirely from how few people and places hold it.
A secret known to too many people is no longer a secret, even before anything bad happens, because every extra copy raises the chance of exposure and destroys accountability. The test before any secret moves is whether this party needs it for a defined job by the proper channel; convenience is never a reason. When several parties need access, issue each its own secret rather than copying one more widely.
Never hardcode a secret into code, where it spreads through copies, version history, and backups and cannot be recalled, and never send one over chat or email, which are persistent, widely copied, and weakly controlled. Store secrets in a secrets manager or vault: encrypted at rest, handed out only to entitled accounts and programs, access recorded, fetched by name at run time. One controlled home means rotation and revocation take effect everywhere at once.
Rotate secrets on a schedule and at triggers. Scheduled rotation is right for machine-generated tokens, keys, and certificates, even though CIS 201 rightly says not to force routine change of human-chosen passwords, because no person memorises them and rotation costs nothing in strength while shortening any leak's life. Rotate at once on a person's departure or role change (the leaver and mover steps of Lesson 02) and on any suspicion of compromise.
Revoke a lost or leaked secret immediately: cancel it so it opens nothing even in the holder's hands, then re-issue. Speed is everything because a leaked digital key can be copied perfectly and used from anywhere at once. For a member the drill is to report any suspected exposure at once, plainly and in full, so the responsible person can revoke it. This is what the lost-or-stolen-device drills of CIS 201 and SIG 220 were racing towards.
Service accounts and machine keys, the secrets used by programs and devices with no person in the loop, are often the most powerful and the most easily forgotten because they never complain. Give each a named human owner, apply least privilege as strictly as to people, and inventory, rotate, and revoke them like any other secret. The leaver process must catch the service accounts and machine secrets a departing person owned or knew.
This lesson builds on the personal credential and certificate care of CIS 201 and the comsec discipline of SIG 220, and sits within CIS 220's access machinery (the lifecycle of Lesson 02, the least privilege of Lesson 03). It hands on to records and data security in Lesson 05, to audit and accountability in Lesson 10, where individual secrets are what make audit trails meaningful, and to incident response and continuity in CIS 310 and HCR 220. Throughout, access follows appointment, never merely a qualification, and the handling of keys is defensive and lawful, in service of protecting the Principality's accounts, keys, records, and the privacy of its nationals.

Protecting Credentials, Keys, and Secrets