The Vega Hill student satellite team had a problem that never made the mission log: nobody could say, on any given Tuesday, who was allowed to command the spacecraft. The team is invented, yet any crew that has operated a modest ground segment will recognise the mess. What follows is how they sorted out AccessOps for their uplink, step by step, and what they would tell the next crew.
The week the antenna schedule went sideways
Their cubesat sat in a polar low orbit, which meant roughly a handful of usable passes per day and a few minutes of contact each. If you want the orbital background, the site has a readable beginner walkthrough of how low Earth orbit behaves; for this story, all that matters is that contact windows are short and unforgiving.
During one pass, a graduate student needed to push a configuration change. She did not have command rights, so she borrowed a teammate’s login on the ground-station laptop. The change worked. The pass ended. Three weeks later, a bad command was traced to that same shared account, and nobody could reconstruct who had typed it. The team lead called a meeting and wrote one sentence on the whiteboard: “Access we cannot explain is access we do not have.”
What AccessOps meant for a ground crew
The lead had been reading the Ops Atlas, which describes AccessOps as the day-to-day work of handling requested and privileged access: how people ask for rights beyond their default, who approves, how elevation is made temporary, and how emergency routes are kept honest. According to the Atlas entry, the Ops Atlas page on AccessOps, the term is an editorial label rather than a formal standard, but it sits on top of well-established practices like privileged access management and just-in-time elevation. That framing suited the team. They did not need a new religion, only a habit.
They split the problem three ways, a division the Atlas also uses. First, who exists: a roster of every person with any link to the ground station. Second, what each person may do: operator, observer, firmware reviewer. Third, how and when somebody gets to do the sensitive thing right now. Only that third question became their AccessOps project; the first two were housekeeping they already half-owned.
The five-field grant
Their first change was cultural. No more standing command rights for everyone with a student badge. Instead, operators were eligible but not active. To go active, a person filed a short grant record with five fields:
- Who is asking, by individual name and never a shared login.
- What exactly they need, such as “upload a configuration file” rather than “admin”.
- Why, written as a task a stranger could understand.
- Until when, measured in hours, not semesters.
- Approved by a named person or by a rule the team agreed in advance.
The “why” field was the surprise. Early entries read “needed for work”, and the lead bounced them back. After a week the entries became concrete: “swap downlink bitrate before pass 14 to test the lower-power mode”. That wording later let them tie a command to an intention, which is exactly what the incident review had lacked.
A grant is not a session
The second lesson came from a test. The team issued a short-lived credential for the ground-station shell, then kept an already-open connection running past the expiry time. The session simply carried on. The Atlas describes the same trap in its own lab, where a remote shell outlived the certificate by about twenty seconds, because that tool checks the certificate only at login. Twenty seconds is nothing on a quiet day. In the middle of a pass, it is the whole command window.
So the crew added two practices. Elevated sessions got their own short idle timeout, and the end of any grant triggered a manual “close all shells for this user” step. It was clumsy, but it matched the real behaviour of their tools instead of the behaviour they wished for.
The emergency path nobody likes to test
Every system also needs an emergency door. For a satellite team, that is the case where the normal approver is asleep and the spacecraft is tumbling. The Atlas calls this a break-glass account: a small number of accounts that stay permanently active by design, protected by strong authentication, with an alarm on every use. It also stresses that such accounts must be tested on a schedule, because a door nobody has opened in a year may not open at all.
Vega Hill ran a drill in the second month. Two people tried to use the emergency credentials at 11 pm. One found the password sheet in the wrong binder. The other had an expired authenticator. They fixed both, and wrote a rule that every drill ends with a short note read at the next team meeting. The alarm that fired during the drill made one more point: an emergency account that does not loudly announce itself is a convenience, and convenience is how emergency doors turn into back doors.
Shaping time limits by risk
Not every action deserved the same leash. They adopted a rough tiering, loosely inspired by the ranges the Atlas lays out. Commands that could permanently alter firmware or disable the radio got the shortest grants, measured in an hour or two and needing a second person. Routine telemetry changes got a few hours. Read-only dashboards stayed standing but were reviewed once a year. The exact numbers matter less than having a table at all, because a table turns arguments into lookups.
Measuring whether it works
After a quarter they tracked four small numbers: how many people held standing command rights (it fell from eleven to three), how long a typical request took to approve, how often an approved grant went unused, and how soon emergency use was reviewed. The unused-grant figure was the most useful. When one in four approved requests expired untouched, they shortened default windows. That echoes the Atlas worked example, where a four-hour default meant far more granted time than used time. Short windows are not about distrust; they are about not paying for access you never use.
What they would tell the next crew
- Start with an inventory of who can command the spacecraft today. It will be longer than you expect.
- Write the five-field grant on a single page and refuse vague “why” entries.
- Test the emergency path before you need it, and keep the alarm loud.
- Remember that expiry does not close a session that is already open.
- Review the numbers monthly; adjust windows by evidence.
The site also carries a calmer companion piece, a plain explanation of geostationary orbit, if you want to see why a ground crew’s contact rhythm differs by orbit. As for the Vega Hill team, their lead still keeps that whiteboard sentence. The satellite is still up, the logs are readable, and the next time a bad command appears, they will know whose name is on it.