Lesson Overview
Lesson 01 established that identity is the master key of a digital state, and that almost every serious compromise comes down to a credential that was stolen, shared, or never taken away. This lesson takes the last of those, the credential that was never taken away, and the wider problem behind it: an account is not a thing you create once and forget. It is born, it changes as a person's role changes, and it should die when the person leaves. Managing that whole life, deliberately and on time, is one of the plainest and most powerful protections a small force has.
The shape of the work is captured in three words used everywhere in the trade: joiner, mover, leaver. A joiner needs an account and exactly the access the role requires, no more. A mover, someone who changes role, needs their access adjusted, which means removing what they no longer need as well as adding what they now do. A leaver needs their account deprovisioned promptly, because a forgotten active account is a serious and well understood way in. Around these three sit two further habits: hunting down orphaned and dormant accounts that no longer belong to anyone or are no longer used, and periodically reviewing who holds what so that access does not quietly drift away from need. Every account in all of this is tied to a real, named person and a real appointment, never to a vague idea of a role.
This is the knowledge layer. It teaches you to recognise each stage, to know what good looks like, and to spot the failures. The hands-on work, provisioning an account in the identity service, running a leaver checklist on a real departure, conducting an access review against the register, is done and signed off in person under the operator responsible for the system, where supervision allows. Reading this does not grant you any access; access follows appointment.
By the end you will be able to describe the joiner, mover, and leaver stages of the account lifecycle and what each requires, explain why a mover must have access removed and not merely added, explain why prompt deprovisioning of a leaver matters and what a forgotten active account risks, recognise orphaned and dormant accounts and describe how a small force finds and removes them, describe a periodic access review or recertification and what it confirms, and tie any account firmly to a named person and a current appointment.
Key Terms
- Account lifecycle: the full life of an account from creation, through every change of role, to its eventual removal; managing it deliberately is the subject of this lesson.
- Provisioning: creating an account and granting it the access its role requires; done at joining and adjusted thereafter.
- Deprovisioning: removing an account's access and disabling or deleting it; done when a person leaves or no longer needs it.
- Joiner: a person who is newly given an account; the task is to provision exactly the access the role needs and no more.
- Mover: a person who changes role or appointment; the task is to adjust their access, adding what is now needed and removing what is not.
- Leaver: a person who is leaving the Army or the appointment; the task is to deprovision promptly and completely.
- Orphaned account: an account with no current owner, often left behind when a person departed and their account was never removed.
- Dormant account: an active account that has not been used for a long time; it may belong to someone, but its disuse makes it a quiet risk.
- Privilege creep: the slow accumulation of access as a person moves between roles and old permissions are never removed; the chief reason movers must lose access, not just gain it.
- Access review (recertification): a periodic check in which the owner of a system, or the person accountable for a role, confirms that everyone who holds access still needs it.
- Joiner-mover-leaver (JML): the standard name for the lifecycle discipline, used across the security trade.
- Appointment: the formal posting that gives a person a role and the authority that goes with it; in Kaharagia, access follows appointment, and ends when the appointment ends.
Why an account has a life, not just a birth
It is tempting to think of an account as a thing you set up once. A person joins, you make them an account, you give them what they ask for, and you move on. This is how most account sprawl begins. The account you created on a person's first day is almost never the account they should hold a year later, two roles on, or the day after they leave. Roles change and people depart, but unless someone deliberately manages the account through those changes, it does not change with them. It keeps whatever it was last given, accumulating access it no longer needs and outliving the person it belonged to.
The discipline that fixes this is to treat every account as having a life with distinct stages, and to act at each one. The trade summarises the stages as joiner, mover, leaver. The point is not the words but the habit: every time a person's relationship to the Army changes, their account must be made to follow, on time. A force that does this well has accounts that always match current need. A force that does not has a growing pile of over-privileged, half-forgotten, and abandoned accounts, which is exactly what an attacker hopes to find.
Here is the lifecycle in one view. Read it left to right as a person's relationship with the Army changes, and notice that the cycle of movement can repeat many times before a person ever leaves.
THE ACCOUNT LIFECYCLE (Joiner, Mover, Leaver)
appointment role change(s) appointment
begins (may repeat often) ends
| | |
v v v
+----------+ provision +----------+ adjust +----------+
| JOINER |-------------->| MOVER |--------------->| LEAVER |
| create | exactly | add what | add AND remove | disable, |
| account, | what the | is now | <------+ | revoke, |
| grant | role needs | needed, | | | reclaim |
| least | | remove | loops | | keys, |
| access | | what is | back | | record |
+----------+ | not +--------+ +----------+
+----------+
| | |
+-----> tied to a named person + a current appointment <+
Failure at any stage leaves an account that no longer matches need:
too much access (Mover not trimmed) or no owner at all (Leaver missed).
Two things hold the whole cycle together and are worth stating before we walk each stage. First, every account is tied to a named, real person and to a current appointment. An account that cannot be traced to a person is already a problem, and an account whose person no longer holds the appointment should no longer hold the access. Second, the principle of least privilege runs through every stage: at joining you grant the least the role needs, at moving you cut back to the least the new role needs, and at leaving you take it all away. Lesson 03 treats least privilege and roles in full; here it is the thread that ties the lifecycle together.
Joiner: provision exactly what the role needs
A joiner is a person newly given an account, on first appointment or on first being granted access to a particular system. The task sounds simple, make them an account, but doing it well means resisting two easy errors: giving too much, and giving without a basis.
Giving too much is the commoner error and the more tempting. It is quicker to grant a generous bundle of access than to work out the precise set a role needs, and it spares you the awkwardness of the new person coming back to ask for more. But every permission granted beyond need is a permission that can be misused, stolen, or forgotten, and the joiner stage is where over-privilege most easily creeps in, because nobody is watching a brand new account closely. The discipline is to provision exactly the access the role requires and no more. If the role genuinely needs more later, that is a small, visible request, far safer than a large invisible grant made on day one.
Giving without a basis is subtler. An account should be created because a person holds an appointment that requires it, not because they asked, not because they hold a qualification, and not because it is convenient. This is the specialities framework's rule in its first application: access follows appointment, not qualification. A member may have completed every cyber course the College offers and still hold no access to a single live system, because access waits on the posting, not the certificate. So the joiner step begins not at the keyboard but at the record: confirm the appointment, confirm what that appointment requires, then provision to that, and tie the new account to the named person so it can always be traced back.
A sound joiner provisioning therefore looks like this. Confirm the person and their appointment against the authoritative record. Determine the least access the appointment needs, ideally by the role it maps to rather than by inventing a bespoke set. Create the account in the identity service so the single sign-on governs it. Enforce strong authentication from the first login, a long passphrase and multi-factor authentication, never a shared or default credential. Where the role needs administrative powers, provision a separate admin account, not elevated rights on the everyday one. Record what was granted and why. Done properly, the joiner stage is the cheapest security you will ever buy, because it is far easier to grant the right access once than to claw back the wrong access later.
Mover: adjust, which means remove as well as add
A mover is a person who changes role or appointment while remaining in the Army. They are promoted, they transfer between sections, they take on a new duty, they hand an old one over. The mover stage is the one most often done badly, and the way it is done badly is almost always the same: access is added for the new role and never removed for the old.
This is how privilege creep happens. A member joins in one role and is given its access. They move to a second role and are given its access too, on top of the first, because adding is easy and nobody stops to ask what the first role's access was for. They move to a third, and now hold the access of three roles though they perform only one. After a few years and a few moves, a single account can hold a startling spread of access, far beyond anything its current appointment needs, assembled one harmless looking addition at a time. Each addition seemed reasonable. The accumulation is dangerous, because that one account, if stolen, now opens far more than the current job would explain, and because nobody can any longer say why most of its access exists.
The rule for the mover stage is therefore one short sentence that is constantly forgotten: a role change means adjust the access, not just add to it. When a person moves, work out the access the new appointment needs and the access the old appointment needed, grant the difference that is genuinely new, and remove everything the old role required that the new one does not. The mover should come out of the change holding exactly what the new appointment needs, no leftovers. The cleanest way to achieve this, where the systems allow it, is to grant access by role rather than to the person directly, so that moving a person to a new role swaps their access wholesale rather than layering new on top of old. Lesson 03 develops that role-based approach; the lifecycle point is simply that a mover must be trimmed, not just topped up.
Leaver: deprovision promptly and completely
A leaver is a person who is leaving the Army, or ending the appointment that gave them access. This is the stage where a missed action is most plainly dangerous, because what is left behind is an active account belonging to someone who is no longer there to use it legitimately, no longer watched, and no longer accountable.
A forgotten active account of a leaver is a serious risk for several reasons at once. It is an open door that nobody is using and so nobody is watching, which is exactly the kind of door an attacker prefers. Its credentials may live on in the former member's password manager, their personal device, or a note, beyond the Army's control. If those credentials are ever breached, in a wholly unrelated leak, the account is a ready way in that no current activity would explain. And because the person has gone, no normal use will ever flag the account as odd, so it can sit live and exposed indefinitely. Most accounts that turn into orphaned accounts began as leavers who were never deprovisioned.
Deprovisioning must therefore be prompt and complete, and prompt means as part of the departure, not weeks later when someone notices. On the day the appointment ends, disable the account in the identity service so no further sign-in is possible. Revoke the person's multi-factor enrolments and any per-user certificates and keys they held, the per-user TAK .p12 being the obvious example, so that a copied key is useless. Reclaim or reset any shared secrets the person knew, because a secret known to a departed person is no longer a secret. Reassign anything the person owned, open records, mailboxes, files, so nothing is stranded behind a dead account. Then record that the leaver was processed, with what was revoked and when, so the departure can be audited later. Disabling first and deleting later is usually wiser than deleting outright, because a disabled account preserves the audit trail and lets you reassign what it owned, while still being firmly shut.
Orphaned and dormant accounts: the quiet way in
Even a force that means well will, over time, accumulate two kinds of dangerous account: orphaned accounts and dormant accounts. They are different, but both are quiet, both are common, and both are favourite footholds for an attacker precisely because nobody is watching them.
An orphaned account has no current owner. It belonged to a leaver who was never deprovisioned, or it was created for a purpose that ended and never cleaned up, or it was a generic login nobody can now tie to a person. Its danger is that no one is accountable for it. No one will notice it being misused, no one will report it stolen, and no normal pattern of use will mark its activity as abnormal, because it has no normal pattern to depart from.
A dormant account, by contrast, may have a real owner, but it has not been used in a long time. The owner moved to other tools, or holds it for a rare task, or simply forgot it. Its danger is that an unused account is an unwatched account: if its credentials were quietly compromised, the legitimate owner, not using it, would never notice the intruder using it. Dormancy turns a live account into a blind spot.
Both are found the same way, by looking, on a schedule, rather than waiting to be surprised. The method is to reconcile the accounts that actually exist in each system against the people and appointments that ought to have them, and to flag the gaps. Here is that hunt as a simple flow.
FINDING ORPHANED AND DORMANT ACCOUNTS
+-----------------------------------------------+
| List every account that exists in a system |
+-----------------------------------------------+
|
v
+-----------------------------------------------+
| For each account, ask two questions: |
| (a) Does it map to a named person with a |
| current appointment that needs it? |
| (b) Has it been used within a sensible |
| recent window (e.g. last 60-90 days)? |
+-----------------------------------------------+
| |
no owner / owner ok but
no appointment not used lately
| |
v v
+-----------+ +-----------+
| ORPHANED | | DORMANT |
+-----------+ +-----------+
| |
v v
+-----------------+ +-------------------------+
| Disable now; | | Confirm with the owner: |
| reclaim owned | | still needed? If yes, |
| items; record; | | keep + note. If no or no |
| then remove | | reply, disable + remove. |
+-----------------+ +-------------------------+
The two enquiries the flow turns on are worth holding in mind. Does this account map to a named person with a current appointment that needs it? If not, it is orphaned, and should be disabled at once and then removed once anything it owns has been reclaimed. Has this account been used within a sensible recent window? If it has an owner but has gone unused, it is dormant, and the right step is to ask the owner whether it is still needed, keeping it only on a clear yes and disabling it otherwise. A small force can run this hunt by hand on a modest schedule, and should, because for a digital state the orphaned admin account is among the most dangerous things that can exist, and the only way to be sure it does not is to look.
Access reviews: confirming that need still holds
The lifecycle stages catch change at the moment it happens: a joiner gets access, a mover is adjusted, a leaver is removed. But moments are missed, mover trims are skipped, leavers slip through, and access drifts away from need without any single visible event. The remedy is to step back periodically and check the whole picture, asking of everyone who holds access whether they still need it. This is the access review, also called recertification, and it is the safety net under the whole lifecycle.
A review is not a hunt for villains. It is a calm, scheduled confirmation. For each system, the person accountable for it, ideally with the person accountable for each role, looks at who currently holds access and confirms, line by line, that each person still has an appointment that needs that access. Anything confirmed is recertified and noted. Anything that cannot be confirmed, the person has moved on, the appointment has ended, nobody can say why the access exists, is removed. Done on a sensible cadence, a review steadily squeezes out the privilege creep, the missed mover trims, and the orphaned and dormant accounts that the day to day lifecycle did not catch. It is also where the audit trail proves its worth, because the record of who was granted what, and when, is what makes a review possible at all. Lesson 10 treats audit and accountability; here, the review is the periodic reckoning that keeps held access honest.
Here is a review as a flow. Notice that the default for anything unconfirmed is removal, not retention: access must be justified to be kept, not justified to be taken away.
ACCESS REVIEW / RECERTIFICATION FLOW
+------------------------------------------------------+
| On a schedule, for one system at a time: |
| list every person who currently holds access |
+------------------------------------------------------+
|
v
+------------------------------------------------------+
| Owner of the system + owner of each role review |
| the list together, line by line |
+------------------------------------------------------+
|
for each line, ask:
"Does this person hold a current appointment
that still needs exactly this access?"
|
+-----------------+------------------+
| |
YES NO / UNSURE
| |
v v
+-----------+ +------------------+
| Recertify | | Remove the |
| and note | | access; record |
| (keep) | | the change |
+-----------+ +------------------+
| |
+------------------+-----------------+
v
+------------------------------------------+
| Record the review: who reviewed, when, |
| what was kept, what was removed |
+------------------------------------------+
Default for anything not positively confirmed: REMOVE.
In Practice: a transfer that should have shed access
Sergeant Adesina serves as the systems assistant for a section, an appointment that gives her an everyday account in the single sign-on and, separately, an admin account for managing user enrolments in one internal service. Both were provisioned when her appointment began, each tied to her name and posting, and her admin powers sit on the separate admin account, never on her everyday one, as the joiner discipline requires.
She is now posted to a new section with a different duty, one that needs her everyday account but no longer needs any user-enrolment admin rights at all. The operator processing the move opens her record, confirms the new appointment against the register, and works out what it requires. The new duty needs her everyday account kept and one new shared records folder added. So far this is the easy half, the adding. The operator then does the half that is usually skipped: he asks what the old appointment gave her that the new one does not need, and finds the enrolment-management admin account. Because her new posting does not call for it, he disables that admin account, revokes its multi-factor enrolment, and records the change with the date and reason. Sergeant Adesina leaves the move holding exactly what her new appointment needs, and nothing left over.
Three months later the service runs its quarterly access review. The operator reviewing the enrolment service lists everyone holding admin rights and goes down it with the person accountable for the service. Every name is checked against a current appointment that needs it. Sergeant Adesina's old admin account does not appear, because the mover step already removed it, which is exactly how a clean lifecycle should feel: the review finds little to do because the day to day discipline already did the work. One name on the list, though, belongs to a member who left the unit two months ago and whose everyday account was deprovisioned at departure, but whose admin account on this one service was missed. The review catches the orphaned admin account, the reviewers cannot confirm any current appointment for it, and it is disabled and removed on the spot, with the gap noted so the leaver checklist can be tightened. The safety net did its job.
Check Your Understanding
- A member moves from one role to a second role. The operator grants the access the second role needs but leaves the first role's access in place, reasoning that it does no harm. What is this failure called, and why is it dangerous?
- A leaver's appointment ended a month ago but their account was never disabled. List at least three specific things that should have happened on the day they left, and explain why a forgotten active account is a serious risk.
- What is the difference between an orphaned account and a dormant account, and what is the default decision for any line of access that cannot be positively confirmed during an access review?
Reflection (write a short paragraph): Think of a system, group, or shared resource you currently have access to, in the Army or in ordinary life, that you were given for a reason that has since passed. Why is it still yours, and who would ever notice and remove it? Write about what your own answer suggests about how access drifts away from need, and what a regular access review is really for.
Summary
- An account has a life, not just a birth: it must be managed through every change, or it drifts away from need and becomes a risk.
- The lifecycle is joiner, mover, leaver. A joiner is provisioned exactly the access the role needs and no more, on the basis of an appointment, not a request or a qualification.
- A mover must have access adjusted, which means removing what the old role needed as well as adding what the new one does; failing to remove is privilege creep, the slow accumulation that makes one account dangerous.
- A leaver must be deprovisioned promptly and completely: disable the account, revoke keys and certificates and multi-factor enrolments, reclaim shared secrets and owned items, and record it. A forgotten active account is an unwatched open door.
- Orphaned accounts (no owner) and dormant accounts (unused) are common footholds; find them on a schedule by reconciling accounts against people and current appointments, and remove what cannot be justified.
- Access reviews, or recertification, periodically confirm that everyone still needs what they hold; the default for anything unconfirmed is removal, not retention.
- Every account is tied to a named person and a current appointment, because access follows appointment, not qualification, and ends when the appointment ends.
- Builds on Lesson 01 · Identity as the Master Key and leads into Lesson 03 · Authorisation, Roles, and Least Privilege, where role-based access makes movers clean and Lesson 10 · Audit, Review, and Accountability, where the records that make reviews possible are treated in full.
- Partners SIG 220 · Communications Security and Digital Discipline, supports PME 210 · Basic Staff Duties and Written Orders (the custody of records and appointments), and feeds CIS 310 · Cyber Incident Response and Continuity, where a stale account is often the first thing an incident exposes.
Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia