Separate Everyday and Administrator Accounts

Separate purpose and privilege before changing accounts

Australian Signals Directorate guidance recommends identifying privileged tasks, validating who is authorized to perform them, creating separate attributable administrative accounts with the least privilege needed, and revalidating continued need. NCSC identity and access management guidance supports least privilege, separate accounts for privileged and day-to-day work, audit records, privileged-user controls, and lifecycle grant and revocation decisions.

Those sources support separation, attribution, least privilege, evidence, and revalidation. They do not prescribe the seven stages, six-layer model, 16 fields, exception rules, or fictional example below. Those are PlainFort editorial choices for a small team—not ASD or NCSC requirements, enterprise PAM architecture, certification, a guarantee, or proof that privilege is mathematically minimal.

Separating accounts cannot make an administration device trustworthy, prove logging works, create authority or competence, guarantee recovery, or show that the organization is secure.

Keep six layers distinct

Do not use admin account as a complete description. Separate:

1. Human or accountable role — who is authorized and internally accountable; not a username.
2. Identity purpose — everyday work or bounded administration.
3. Role or entitlement — the capability granted to the identity.
4. Session or elevation event — when privilege begins, for which task, and when it ends.
5. Device or execution environment — where the privileged work occurs; separate identity does not secure it.
6. Privilege scope — the least capability necessary for the bounded task, not a generic admin assumption.

Local-device, cloud, infrastructure, production, and provider-operated administration can be recorded as generic categories only. Do not infer platform roles, elevation features, logging, session recording, or recovery behavior. Use Unknown — qualified review required when the real boundary cannot be established from current primary documentation.

Keep routine activity out of unnecessary privilege

Routine email, web browsing, messaging, document handling, downloads, and ordinary collaboration should not occur under unnecessary administrative capability. This reduces the reach of routine compromise and error; it does not make the everyday identity safe.

For each privileged task, state why privilege is required, the narrow system and capability boundary, the attributable path that may perform it, what begins and ends the session, what evidence is expected, and when continued need is revalidated. Never describe a permission set as least privilege verified merely because a worksheet is complete.

Use seven stages without hiding an exception

The sequence, feasibility threshold, states, fields, and completion test below are PlainFort editorial judgment. They may be simplified for a small team only when the simplification does not hide attribution, authority, continuity, recovery, or excessive privilege.

1. Map privileged tasks before accounts

List bounded changes that require elevated capability, their business impact, non-secret evidence, and internal owner. Do not begin by cloning every existing administrator into the new design.

2. Map current identities and privilege paths

Record controlled non-secret references for everyday identity, administrative identity, standing entitlement, elevation path, session/environment, and unknown shared or provider access. Do not record usernames, endpoints, credentials, or configuration.

3. Define the everyday boundary

Name routine activities that remain outside privileged sessions and the observable trigger for switching to administration. The everyday identity does not inherit administrative capability merely for convenience.

4. Define attributable administration

For each task, use either a separate attributable administrative identity or a documented bounded-elevation pattern where the system supports it. Record the least-necessary rationale, authorized executor, accountable internal owner, and evidence. Do not assume just-in-time elevation or granular roles exist.

5. Bound privileged use

State the task, session or elevation start and end, device/environment assumption, prohibited routine activity, evidence location, and revalidation trigger. This is an operating boundary, not a platform command or live session.

6. Prepare continuity and recovery

Confirm backup coverage, last-administrator risk, AA-06 credential-handling reference, AA-07 method/recovery reference, business interruption boundary, and escalation. Stop before any live account or privilege change.

7. Record exceptions and revalidate

Preserve the reason, owner, scope, compensating boundary, evidence, expiry or observable exit, residual risk, escalation, and next review. An exception without an owner or expiry is Unbounded exception — escalate, not completion.

Compare two generic patterns, not products

A small team may use a separate attributable administrative identity used only for privileged work, or an attributable everyday identity that invokes a documented, bounded elevation mechanism. Neither pattern is universally available or sufficient.

The choice depends on actual supported capabilities, attribution, device/environment trust, AA-07 authentication and recovery decisions, continuity, accessibility, and impact. Do not assume time-bounded elevation, granular roles, session recording, logs, or uniform removal. Standing privilege that cannot yet be removed remains an exception with owner, scope, expiry, evidence, and residual risk.

Stop before lockout or loss of administration

Before any separately authorized account creation, privilege grant/removal, elevation, or recovery, stop and confirm:

• an accountable internal owner and authorized executor;
• current surviving administrative and recovery authority;
• whether the change affects the last viable administrator;
• approved AA-06 and AA-07 decision references where applicable;
• a non-secret continuity or rollback plan;
• business impact and acceptable interruption;
• backup coverage that is real rather than merely named;
• whether qualified product, IT, security, accessibility, legal, contractual, or incident help is required.

This guide does not create or modify accounts, grant or remove privilege, perform elevation, sign in administratively, test recovery, or change production access. Use Blocked — qualified help required when authority, continuity, provider behavior, or surviving administration is unclear.

Break-glass is a narrowly scoped emergency-access pattern, not the normal administrative identity, an informal shared login, or permanent unrestricted privilege. It requires purpose, internal owner, authorized roles, protected storage outside this article, access control, logging where available, a review/test trigger, post-use review or rotation where applicable, and expiry or exit. This guide does not create, configure, reveal, or test a break-glass path.

Preserve sibling ownership

AA-06 owns password-manager rollout and individually attributable credential migration. AA-08 may require an approved AA-06 reference; it does not select a product, repeat rollout, migrate a credential, or record a secret.

AA-07 owns MFA-method selection, phishing-resistance evidence, fallback, device replacement, accessibility, and recovery tradeoffs. AA-08 may consume an approved AA-07 reference for the administrative scenario; it does not select, configure, enroll, or recover a method.

AA-09 owns departure-triggered revocation, effective time, authority, session closure, device handoff, evidence, and exceptions. AA-08 defines the steady-state privileged boundary; it does not execute offboarding.

AA-10 owns whether a shared administrative login is eliminated, replaced with individual accounts, delegated, brokered, placed in controlled shared access, or retained as an exception. Mark non-attributable privilege AA-10 decision required; do not normalize sharing or reproduce that decision tree.

A contractor or provider may execute or consult under a bounded authorized arrangement, but does not implicitly acquire the team’s internal accountability. Operational vendor-access fields remain in SF-05; this guide records only the non-secret privilege-design dependency.

Use a 16-field vertical administrative-account map

Use one vertical block per bounded privileged task and system. Avoid a wide PAM or RACI table.

1. Bounded privileged task and non-secret system reference — task category and invented/controlled reference; no configuration or endpoint.
2. Business impact and prohibited routine activity — impact if misused plus email, browsing, messaging, documents, or downloads excluded from privileged use.
3. Accountable internal owner — accountable role; naming it does not create authority or competence.
4. Authorized executor role — role permitted to perform the task; not a username.
5. Everyday identity purpose — routine work boundary and activities; no account identifier.
6. Administrative identity or elevation purpose — bounded use only; no platform instructions.
7. Privilege scope and least-necessary rationale — required capability and uncertainty; not proof of mathematical minimum.
8. Standing privilege or elevation state — documented state such as Bounded elevation or Standing privilege — exception.
9. Session start/end and use boundary — trigger, task, end condition, and prohibited routine activity.
10. Device or execution-environment assumption — non-secret trust assumption and unresolved gap; no device ID, host, or IP.
11. AA-06 credential-handling reference — approved decision reference or AA-06 decision required; no secret.
12. AA-07 MFA/recovery decision reference — approved decision reference or AA-07 decision required; no method configuration or recovery material.
13. Attribution, audit, completion evidence, and location — what was inspected and where a non-secret record belongs; not a claim that logging is complete.
14. Backup, continuity, last-administrator, and escalation state — real coverage, stop condition, and destination.
15. Exception, owner, expiry/exit, and residual risk — explicit exception boundary; missing owner/expiry means escalation.
16. Revalidation or review trigger — role, task, provider, privilege, device, recovery, incident, departure, evidence, or exception change.

Useful states include Everyday only, Separate attributable admin, Bounded elevation, Standing privilege — exception, Unknown — follow up, Blocked — last administrator, Blocked — authority unclear, AA-06 decision required, AA-07 decision required, AA-10 decision required, and Unbounded exception — escalate. These are workflow states, not scores, certifications, proof of least privilege, or proof of security.

Fictional example — do not copy as a completed administrative-account design

Example Co. is mapping the invented task ExampleCloud — change organization-wide settings. No real person, account, tenant, role assignment, device, endpoint, configuration, credential, or hands-on result is represented.

1. Bounded privileged task and non-secret system reference: Organization-wide settings — ExampleCloud T-01.
2. Business impact and prohibited routine activity: material service interruption is possible; email, browsing, messages, documents, and downloads are prohibited during privileged use.
3. Accountable internal owner: Operations lead; authority must still be verified.
4. Authorized executor role: Authorized administrator role; no identity is recorded.
5. Everyday identity purpose: routine collaboration only, with no administrative purpose.
6. Administrative identity or elevation purpose: Separate attributable admin — proposed for bounded settings task; no account is created here.
7. Privilege scope and least-necessary rationale: organization settings capability appears necessary; granularity is Unknown — qualified review required.
8. Standing privilege or elevation state: Standing privilege — exception because bounded elevation support is not established.
9. Session start/end and use boundary: begins after an authorized task reference; ends after evidence capture and sign-out; routine activity remains prohibited.
10. Device or execution-environment assumption: Dedicated approved environment expected — evidence not yet established; no identifier is stored.
11. AA-06 credential-handling reference: AA-06 approved reference — value not recorded.
12. AA-07 MFA/recovery decision reference: AA-07 approved reference — method and recovery material not recorded.
13. Attribution, audit, completion evidence, and location: task authorization and non-secret completion record expected in Evidence E-01; logging coverage remains unproven.
14. Backup, continuity, last-administrator, and escalation state: Blocked — last administrator until a second authorized path and continuity evidence exist.
15. Exception, owner, expiry/exit, and residual risk: Operations lead owns the standing-privilege exception; exit when supported bounded elevation or another approved pattern is established; review at the next authorized checkpoint.
16. Revalidation or review trigger: role, task, provider, privilege, device, or recovery change; exception expiry; departure; suspected compromise; or contradictory evidence.

The example deliberately leaves a live change blocked. It does not claim that a proposed identity, reference, or evidence location proves secure administration.

Know what completion means

Completion means each bounded task has a truthful purpose, attributable path, privilege rationale, session/use boundary, AA-06/AA-07 dependencies, evidence, continuity state, exception/expiry, residual risk, and review trigger. It does not prove least privilege, logging completeness, device integrity, authority, competence, successful recovery, independent backup, or security.