Privileged Access Standard for Client Environments

Privileged Access Standard for Client Environments

Document ID: BP-STD-021

Version: 4.2

Owner: Chief Information Security Officer

Approved by: Executive Team, 2026-05-19

Effective: 2026-06-01

Review cadence: Every 6 months, or within 10 business days of any privileged-access incident

Next scheduled review: 2026-12-01

---

1. Purpose and threat model

A managed service provider holds privileged access to every client it serves.

That concentration is the reason clients hire us and the reason we are a target:

an attacker who compromises one Brightpath technician account can reach several

hundred client tenants at once. Published incidents in our sector have followed

exactly this path — compromise of provider tooling or provider identity,

followed by fan-out through legitimate management channels.

This standard therefore assumes **the attacker is already inside a Brightpath

identity** and asks what limits the damage. Controls are selected to reduce

blast radius, not only to reduce likelihood.

2. Scope

Applies to all Brightpath personnel and contractors with any administrative

access to a client environment, and to the tooling that carries such access:

RMM, PSA, backup console, EDR console, identity management, and any per-client

delegated administration.

Out of scope: access to Brightpath's own corporate systems, covered by

BP-STD-007. Client staff privileges within their own tenant, which the client

governs and we advise on.

3. Principles

• No shared credentials, ever. Every privileged action is attributable to

one named human.

• No standing privilege. Elevation is requested, time-boxed and expires.
• Least privilege per tenant. Access to one client grants nothing in

another.

• Enforced technically, not by policy. A rule that depends on people

remembering it is a rule we assume is broken.

• Every privileged session is reconstructable after the fact.

4. Identity and authentication

Control · Requirement · Enforcement

Technician identity · One named account per person, per system. No role or team accounts. · Conditional access blocks unnamed accounts

MFA · Phishing-resistant only — FIDO2 security key or platform passkey · Conditional access; SMS and TOTP are blocked, not discouraged

Device · Privileged access only from a Brightpath-managed, compliant, encrypted device · Device compliance policy; non-compliant devices are denied

Network · No IP allowlist dependency · Deliberate: see §11

TOTP and SMS were removed as acceptable second factors on 2026-03-30 following

a phishing simulation in which 3 of 41 technicians relayed a TOTP code to a

proxy. Zero relayed a FIDO2 assertion, because the protocol makes it impossible

rather than making it inadvisable.

5. Standing privilege and elevation

No technician holds standing administrative rights in any client tenant.

• Baseline access is a read-only support role sufficient for triage.
• Administrative elevation is requested in the PSA against a ticket, approved by

a Service Desk Lead or above, and granted for 4 hours, after which it is

removed automatically.

• Elevation requests record the ticket, the client, the scope requested and the

business reason. Approval and grant are separate events with separate actors.

• Out-of-hours elevation may be self-approved by on-call engineers to avoid a

recovery being blocked at 03:00. Self-approved elevations are reviewed by the

CISO the following business day, and a self-approval that cannot be tied to a

genuine incident is treated as a policy violation.

Current metric: 96.4% of privileged sessions in the last 90 days were

covered by an approved, time-boxed elevation. The residual 3.6% is break-glass

and self-approved out-of-hours use, all reviewed.

6. Per-client separation

• Client tenants are administered through **delegated administration scoped per

tenant and per role**. Global administrator delegation is not used, and is

blocked at the partner-tenant level rather than discouraged.

• Local administrator credentials on client endpoints are unique per device,

generated and rotated automatically every 24 hours, and retrieved from the

vault against a ticket. Retrieval is logged with the retrieving technician,

the device and the ticket.

• No credential is reused across two clients. This is verified by a monthly

automated scan that hashes stored credentials and reports collisions.

Last scan 2026-08-03: zero collisions across 4,812 stored credentials.

7. Tooling access

Our management tooling is itself a privileged path into every client, so it is

treated as production infrastructure rather than as internal software.

• RMM script execution against more than 25 endpoints simultaneously requires

a second approver. This is a deliberate brake on the exact fan-out pattern

used in provider-compromise incidents.

• Deployment packages are built per tenant with per-tenant enrolment tokens. No

global enrolment key exists; one was retired on 2025-11-14.

• Backup console deletion of restore points requires two approvers and is

irreversible for 30 days by vendor-side immutability.

• All four consoles federate to Brightpath identity, so deprovisioning is a

single action rather than four.

8. Break-glass

Two break-glass accounts exist per critical system, for the case where

federation itself is unavailable.

• Credentials are split into two halves held by different executives in separate

sealed physical envelopes.

• Accounts are excluded from conditional access by necessity, and are therefore

monitored with a dedicated alert on any authentication, routed to the CISO and

the on-call lead simultaneously.

• Tested quarterly. Last test 2026-07-08: both accounts authenticated, alert

fired in 41 seconds, envelopes resealed and re-witnessed. Next test 2026-10-08.

• Any real use requires a post-incident review within 5 business days.

9. Session audit

• All privileged sessions to client environments are recorded, including

commands executed through the RMM.

• Recordings are retained 13 months, matching the longest client contractual

audit window plus one month.

• Access to recordings is restricted to the CISO and the Head of Service

Delivery, is itself logged, and cannot be granted by the person under review.

• Recordings are stored in a separate tenant from production tooling, so

compromise of the tooling does not grant the ability to erase the evidence of

what was done with it.

10. Joiners, movers and leavers

• Deprovisioning is triggered by the HR system, not by a manager remembering.

Target is complete revocation within 1 hour of termination; measured

median over the last 12 leavers is 11 minutes, longest 47 minutes.

• A weekly reconciliation compares active identities in all four consoles

against the HR active-employee list. Discrepancies are tickets, not emails.

Last four reconciliations: zero orphaned accounts.

• Role changes trigger re-entitlement rather than accumulation. A technician

moving from service desk to projects loses service desk scope on the same day.

• Contractors are provisioned with a mandatory end date that cannot be set

beyond the contract end recorded in the PSA.

11. Accepted risks and rejected alternatives

Stated explicitly so a future reader knows these were decisions rather than

oversights.

IP allowlisting was rejected. It fails open for a stolen session token and

fails closed for a legitimate engineer at a client site during an outage. It

would have added meaningful operational risk during exactly the incidents where

we are most needed, in exchange for stopping an attacker who can rent a VPS.

Device compliance was chosen instead, which binds access to a machine we control

rather than to a network location anyone can be standing in.

**Accepted: 4-hour elevation windows are longer than strictly necessary for most

tickets.** A 1-hour window was trialled in February 2026 and produced 340

re-elevation requests in three weeks, which degraded response times and trained

technicians to request elevation reflexively at the start of every shift. Four

hours is a deliberate trade of theoretical exposure against a behaviour we

judged worse.

**Accepted: session recording does not cover client-side remote sessions

initiated by the client.** We record what we do; we cannot record what the

client's own staff do in their own tenant. Clients are told this in the MSA.

Accepted: two people can, in combination, delete backups. Requiring three

approvers was modelled and would have exceeded our on-call headcount at night.

Vendor-side 30-day immutability is the compensating control.

12. Exceptions

Exceptions require CISO approval, a documented compensating control, and a

mandatory expiry of no more than 90 days. Exceptions cannot be renewed more

than once without executive review. The exception register is reviewed monthly.

Open exceptions as at 2026-08-01: two. Both relate to a client's legacy

line-of-business application that cannot support delegated administration; both

expire 2026-09-15 and are tracked against the client's migration project.

13. Measurement

Metric · Target · Current (90 days)

Privileged sessions under approved elevation · ≥ 95% · 96.4%

Credential collisions across clients · 0 · 0

Median revocation time on termination · ≤ 60 min · 11 min

Orphaned accounts at weekly reconciliation · 0 · 0

Break-glass tests completed on schedule · 4/4 · 4/4

Open exceptions past expiry · 0 · 0

Metrics are reported to the Executive Team monthly and to clients on request.

14. Related documents

• BP-STD-007 Corporate Access Control
• BP-POL-009 Incident Response Policy
• BP-POL-014 Backup and Disaster Recovery Policy
• BP-RUN-003 Break-glass Procedure