Royal Army College

Lesson Overview

The earlier lessons in this course taught you how the Principality's systems are built and kept running: servers and services, the network, identity and single sign-on, patching and monitoring, backups and continuity, where systems are hosted, how containers run them, how they are configured and hardened, and how they are documented and automated. This final lesson is about the person standing in front of all of that with the ability to change it. Elevated access, often called administrative or privileged access, is the power to do things an ordinary account cannot: create and remove accounts, alter configuration, read or move data across a service, restart or shut down systems, hold the keys and the secrets that other systems trust. It is the difference between using a system and being able to break it. That power is the subject of this lesson, and the subject is not really technical at all. It is conduct.

A small force cannot afford a large IT department, so the few members it trusts with elevated access carry a weight out of all proportion to their number. Whoever holds the Principality's systems holds its continuity and its nationals' data. A careless or undisciplined administrator can do more damage in a quiet afternoon than any outside attacker, not from malice but from a single undocumented change on a live system, a credential left where it should not be, or access used for a purpose it was never granted for. This lesson is the discipline that keeps that from happening. It is the same disciplined, defensive mindset you met in CIS 201 and in SIG 220, applied now to the people who hold the keys.

This is the knowledge layer. Reading it will teach you the principles and the drill, but the habit is built by doing, under supervision, with real accountability: requesting access through the proper channel, recording a change before you make it, working from a separate admin account, and knowing when to stop and call someone are practised and signed off in person where supervision allows. By the end you will be able to explain why access follows appointment and not qualification; apply least privilege and use access only for its granted purpose; document a change so it can be understood and undone; explain why undocumented or untested changes on a live system are forbidden; protect credentials, keys, and service accounts as the high-value assets they are; recognise when to stop and escalate rather than press on; and describe the trust that holding the Principality's systems places on you.

Key Terms

Elevated access (privileged access): the ability to make changes an ordinary user cannot, for example administering accounts, altering a service's configuration, reading data across a system, or restarting and shutting down systems. Also called administrative or root access.
Appointment: the role and authority a person has been given by the responsible authority. Access follows appointment: you hold the access your role needs, granted by the person responsible for the system, and no more.
Least privilege: the principle that an account is given only the access its task or role needs, and no more. The opposite, an account that can do everything just in case, is the single most dangerous thing in a system.
Separate admin account: a distinct, well-protected account used only for administrative work, kept apart from the everyday account used for email and browsing, so that ordinary risk does not reach the powerful account.
Change discipline: the practice of planning a change, recording it before you make it, having a way to undo it, and never making undocumented or untested changes on a live system.
Live system (production): a system that is actually in use by the force or its nationals right now. A change here affects real people and real data immediately, which is why it demands the most care.
Credential: anything that proves who an account is and lets it in, for example a password, a passphrase, an MFA device, a passkey, or an API token. Treat every credential as the access it unlocks.
Key: a cryptographic secret, for example a per-user certificate (such as a TAK .p12), an SSH private key, or a TLS private key, that proves identity or protects data. A leaked key is a leaked identity.
Service account: a non-human account that lets one machine or service talk to another. Service accounts are often powerful, rarely watched by a human, and so must be guarded with particular care.
Escalation: stopping and handing a problem to the right person or authority when it is beyond your appointment, your competence, or your certainty. Escalating early is a sign of good judgement, not of weakness.
Audit log: the record of who did what, when, on a system. Your documented changes and the system's own logs together let the force understand and, if needed, reverse what was done.

Access follows appointment, not qualification

The first and most important idea in this lesson is one you have already met in this course and in the wider specialities framework, and it is worth stating plainly because everything else rests on it. Finishing CIS 210, or any course, does not grant you access to anything. A qualification tells the force that you are capable of being trusted with a kind of work. The access itself is a separate act: it is granted by the authority responsible for a particular system, to a particular person, for a particular appointment, and it lasts only as long as that appointment does. A soldier does not get the keys to a system because they hold a certificate, any more than passing a driving test entitles them to take any vehicle they please.

This matters for a reason that is easy to miss. In a small, willing force full of capable people, the temptation is always to let competence stand in for authority: someone knows how to fix a thing, so they quietly fix it. That instinct is generous and it is also exactly how systems get damaged and how trust breaks down. The whole point of tying access to appointment is that the force, not the individual, decides who may touch what, and can answer at any time the question that every secure organisation must be able to answer: who has access to this, and why. An access that nobody authorised is an access that nobody can account for.

So before you ever use elevated access, the discipline begins with a question about your own standing. Has this access been granted to me, by the person responsible for this system, for the appointment I currently hold? If yes, you may act within it. If you are not certain, you do not act and then explain later; you ask first. The decision table below is the one to carry in your head.

ACCESS FOLLOWS APPOINTMENT  ·  may I act?

  Granted by    For my current   Within the      For its granted
  the system    appointment?     scope of that   purpose?           VERDICT
  authority?                     access?
  -----------   --------------   -------------   ---------------   -----------------
     yes            yes              yes              yes           ACT, and document
     yes            yes              yes              no            STOP. wrong purpose
     yes            yes              no               --            STOP. out of scope
     yes            no  (role        --               --            STOP. access stale,
                        ended/                                      should be revoked
                        changed)
     no             --               --               --            STOP. not authorised
   not sure         --               --               --            ESCALATE. ask first

Two of these rows deserve a word. The "wrong purpose" row is the one people rationalise away: I have the access, so surely it is fine to use it for this other thing. It is not. Access is granted for a purpose, and using it for another, however harmless it seems, is a breach of trust even where it breaks no system. The "access stale" row is the quiet danger: access that was right for a role you have since left or changed should be revoked, and if it has not been, the disciplined thing is to flag it for removal, not to keep using it because it still works.

Least privilege and using access only for its purpose

If access follows appointment, then least privilege is how much access an appointment should carry: the least that lets the task be done, and no more. An account that can do everything is convenient right up to the moment it is compromised or makes a mistake, and then it can do everything wrong. The CIS essential cyber-hygiene controls, the baseline for a small force like ours, put controlled use of administrative privilege near the heart of the list for exactly this reason. Most of the damage in most incidents flows through an over-powered account.

In practice least privilege has a few plain habits. Keep a separate admin account from your everyday one, and do your ordinary email and browsing as the everyday user, so that a phishing link or a dodgy attachment lands on the weak account and not the powerful one. Use the elevated account only when the task actually needs it, and drop back to the ordinary one when it does not. Ask for access scoped to the job: if you need to administer one service, you should not be handed the keys to all of them. And when a piece of work is finished, or your role moves on, the access that supported it should be removed, not left lying about. Prompt deprovisioning, which you met in the identity lesson, is the same idea seen from the system's side: access ends when the reason for it ends.

Using access only for its purpose is the conduct that sits on top of all this. Elevated access very often lets you see and do far more than your task requires. An administrator of a records system can usually read records that have nothing to do with the change they were asked to make. The discipline is to look only at what the task needs and to touch only what the task needs, even though the system would let you do more. The data belongs to the force and to its nationals; your access is a trust to act on their behalf, not a licence to satisfy curiosity. Reading a national's record because you can, and not because the work required it, is a breach even if you change nothing. Treat the reach of your access as a responsibility to restrain, not a permission to use.

Change discipline: never undocumented, never untested on a live system

Lesson 04 introduced change discipline as part of keeping systems running. Here it becomes a matter of conduct, because the person with elevated access is the one who can break a live system, and almost always does so not by doing something forbidden but by doing something reasonable without care. The two rules at the centre of change discipline are simple and absolute for an administrator of Kaharagian systems: never make a change you cannot account for, and never make an untested change on a live system.

To account for a change means that before you touch anything, it is written down: what you are going to change, why, when, and how you would undo it. This is not bureaucracy for its own sake. The force cannot depend on one person's memory, and an undocumented change is invisible the moment its author is unavailable. When a service misbehaves a day later, the documented change is the first thing the team looks at, and a change nobody recorded is a fault nobody can trace. Your own note and the system's audit log together are what let the force understand and, if it must, reverse what was done. A change you made and did not record is, from the force's point of view, a change that happened by itself.

To avoid untested changes on a live system means you do not try things out on the system real people are using right now. Where there is a test or staging copy, a change is proven there first. Where there is not, the change is made small, planned, made at a sensible time, and made with the way back already in hand: a backup taken first, the previous configuration kept, a tested path to undo it. The instinct to "just quickly try" something on a live service is the instinct that takes services down, and it is precisely the instinct that elevated access makes dangerous, because the powerful account is the one that can quickly try something irreversible. The checklist below is the drill to run in your head, every time, before a privileged action.

PRIVILEGED-ACTION DISCIPLINE CHECKLIST   (run before every change)

  [ ] APPOINTMENT   Is this within access granted to me, for my role,
                    for its purpose?              ...... if no  -> STOP / escalate

  [ ] LEAST         Am I using the right account (admin, not everyday)
                    and the least access the task needs?

  [ ] PLAN          Do I know exactly what I will change, and why?

  [ ] RECORD        Have I written it down BEFORE acting: what / why /
                    when / how to undo?

  [ ] SAFETY NET    Backup taken or known-good config kept?  A tested
                    way back?                     ...... if no  -> do not proceed

  [ ] TEST FIRST    Proven on a test/staging copy, or made small and
                    reversible on live?

  [ ] RIGHT TIME    A sensible moment, low impact on users, someone
                    reachable if it goes wrong?

  [ ] ACT           Make the change. Watch it. Confirm it did what was
                    intended and nothing else.

  [ ] CLOSE         Update the record with what actually happened.
                    Leave the system documented, not just changed.

If any line in that checklist cannot be ticked honestly, the answer is not to press on and hope. It is to stop.

Protecting credentials, keys, and service accounts

The person with elevated access does not only act on systems; they hold the secrets that let systems trust each other, and those secrets are among the highest-value things in the whole estate. A credential, a key, or a service-account token is not a detail of the job. It is the access itself, reduced to something small enough to be copied, lost, or stolen. Protecting it is therefore not housekeeping; it is the core of the trust.

Treat every credential as the access it unlocks. Use a password manager and long unique passphrases, never reused, exactly as CIS 201 taught, and protect the powerful accounts with phishing-resistant MFA, a passkey or hardware security key for preference. Never share an administrative login, because a shared account is one nobody can be held to and one whose access cannot be cleanly revoked from a single person. Never paste a secret into a chat message, an email, a code comment, a ticket, or a screenshot, because each of those is a place the secret will quietly outlive the moment and wait to be found. When a secret must be handed over, hand it over through the means the force has agreed for the purpose, and change it afterwards if there is any doubt about where it has been.

Keys deserve their own caution because a leaked key is a leaked identity. The Principality issues per-user certificates and keys, the TAK .p12 is one example, and the holder of such a key can act as that identity until it is revoked. Keep keys on the device they belong to, protected by the device's own encryption and lock; do not copy them about or email them to yourself for convenience; and report a lost or stolen device at once so its keys and access can be revoked before anyone else uses them. Service accounts, the non-human accounts that let machines talk to each other, are the quiet risk: they are often powerful, they rarely have a human watching their behaviour, and their credentials sit in configuration where they can be forgotten. Guard them as you would the most powerful human account, give them the least privilege their job needs, and rotate or retire them deliberately rather than leaving an old, over-powered service account live because nothing has obviously broken.

Knowing when to stop and escalate

The last discipline is the one that separates a safe administrator from a dangerous one, and it is the hardest for a capable person to practise: knowing when to stop. Elevated access tempts you to solve every problem yourself, because you almost always can do something, and doing something feels more responsible than standing back. But the question is never whether you can act. It is whether acting now, alone, on this, is within your appointment, your competence, and your certainty. When the answer to any of those is no, the right move is to stop and escalate, to hand the problem to the person or authority who should hold it.

Escalate when the work is beyond your appointment, when you are about to touch something outside the access you were granted, when a change has gone wrong and you are not sure how to safely undo it, when you suspect an incident such as a compromised account or a leaked key, or simply when you are not certain and the action is one you could not cleanly reverse. There is no shame in this, and a force that treats early escalation as failure teaches its administrators to hide trouble until it is too large to hide, which is the worst possible outcome. The honest "I have stopped, here is what I see, I need a decision" is worth more to the Principality than the confident change that quietly breaks something nobody notices for a week. This is the same no-blame reporting discipline you met in CIS 201, seen from the side of the person holding the keys, and it leads straight on to CIS 310, where the handling of real incidents is the specialist's whole work.

In Practice: A Records Edit That Should Have Been Two Steps

A systems assistant, Corporal Atero, holds a recently granted appointment supporting the records system. A duty officer messages late one evening: a national's record has a wrong entry, please fix it before the morning. Atero has the access, knows how to make the edit, and the temptation is to open the live records system and correct it on the spot.

Instead she runs the discipline. Appointment: the access was granted for supporting this system, and correcting a recorded error is within its purpose, so far so good. But the checklist's next lines give her pause. There is no test copy of live records to prove the edit on, the change touches a real national's data, and a late-night fix made tired and alone is exactly the kind that goes wrong unrecorded. So she does two things. First she writes, before touching anything, what she will change, the old value and the new, why, and how she would put the old value back. Then she notices the row she nearly skipped over: she is not certain the requested correction is the right one, only that it differs from what the officer says. That is a judgement about the record's truth, not about the system, and it is above her appointment to decide alone at midnight. She stops. She replies that she has the change ready and documented, but that confirming the correct value is a decision for the responsible authority, and asks for it to be confirmed in the morning before she applies it.

Nothing dramatic happened, and that is the point. She used only the access her task needed, from her admin account, not her everyday one; she touched only the one record, not the others she could have read; she recorded the change before making it; and when the work crossed from "fix the system" into "decide the truth of a record", she escalated instead of pressing on. The error was corrected the next day, with the right value, by the right authority, and traceably. An undisciplined assistant would have made a fast, unrecorded, possibly wrong edit to a national's record in the dark, and the force would have had no way to know what was changed or why.

Check Your Understanding

A member who has just passed CIS 210 asks why that does not let them log in and help administer a service they understand well. Explain, in terms of appointment and qualification, why understanding a system is not the same as being granted access to it.
You are about to make a configuration change on a live service. List the things the privileged-action discipline requires you to have in place before you touch it, and explain why making an undocumented or untested change on a live system is forbidden.
You find that a service account's token has been pasted into an old chat message, and that the account is more powerful than its job seems to need. Explain why both of these are problems, and what the disciplined response is.

Reflection (write a short paragraph): Think about the sentence "whoever holds the Principality's systems holds its continuity and its nationals' data." Write about what that weight would mean for how you would conduct yourself if you were granted elevated access, and about one habit from this lesson you think you would find hardest to keep when you were busy, tired, or sure you were right.

Summary

Elevated access is the power to change or break systems, and the subject of this lesson is conduct, not technique. Whoever holds the Principality's systems holds its continuity and its nationals' data.
Access follows appointment, not qualification. A course makes you capable of being trusted; access is granted separately by the system's authority, for a role and a purpose, and lasts only as long as the appointment. When unsure of your standing, ask first; do not act and explain later.
Apply least privilege: keep a separate admin account, use elevated access only when the task needs it, scope access to the job, and give it up when the role or the work ends. Use access only for its granted purpose, and restrain the reach it gives you over data that belongs to the force and its nationals.
Keep change discipline: never make a change you cannot account for, and never make an untested change on a live system. Record what / why / when / how-to-undo before acting; keep a safety net; prove changes on a test copy or make them small and reversible; close the record with what actually happened.
Protect credentials, keys, and service accounts as the access they are. No sharing, no pasting secrets into chats or tickets, phishing-resistant MFA on powerful accounts, keys kept on their device and revoked fast when lost, and service accounts guarded, least-privileged, and retired deliberately.
Know when to stop and escalate. Escalating early when a thing is beyond your appointment, competence, or certainty is good judgement, not failure, and it is what keeps small problems from becoming large ones.
This lesson completes CIS 210 and draws directly on CIS 201 · Digital Security and Cyber Hygiene (credentials, MFA, no-blame reporting) and on the discipline of SIG 220 · Communications Security and Digital Discipline. It deepens in CIS 220 · Identity, Access, and Records Security (access and identity in depth) and leads on to CIS 310 · Cyber Incident Response and Continuity (handling incidents), with continuity shared by HCR 220 · Emergency Preparedness and Civil Resilience.

Working Safely with Elevated Access