Changing the only administrator on a SaaS tenant is not an ordinary profile edit. The request may arrive after an employee leaves, a company changes ownership, an email domain expires, or an attacker gains access to a mailbox. Support must restore legitimate control without turning a persuasive ticket into a privilege-escalation path. This study protocol asks a practical question: when customers request an administrator change, can the service show that the requester was authenticated, the change was authorized, warning signs were reviewed, and the resulting privilege was recorded?
The protocol describes a proposed observational review, not completed research. It does not supply a benchmark approval rate or claim that a particular control prevents account takeover. Its purpose is to make a future review reproducible and to expose cases where the available record cannot support a conclusion.
Define the decision before sampling tickets
The unit of analysis is one request to add, replace, recover, or remove a tenant administrator. A request remains one unit even if it moves between support, security, billing, and legal queues. Duplicate tickets are linked to the earliest request rather than counted as separate attempts. A later request becomes a new unit only when it presents new authority, concerns a different tenant, or follows a completed decision.
The primary outcome has four states: approved and implemented, rejected, withdrawn, or unresolved at the end of the observation window. “Implemented” requires evidence that the intended account received the intended role; an agent’s promise or an internal approval alone is insufficient. Researchers should also record whether the former administrator retained access, because adding a successor and removing a departed employee are different control decisions.
The cohort should cover a fixed period and include every administrator-change request found through ticket tags, security escalations, and privileged-role audit events. Relying on a support tag alone would omit requests that began as login or billing cases. The study must publish the search rules, extraction time, tenant exclusions, and the number of records discovered by each source.
Build an event chronology instead of a ticket summary
Each case needs an ordered chronology drawn from the original systems. Useful events include ticket creation, requester authentication, documents or corporate records received, approval by an existing administrator, security escalation, role grant, session revocation, former-admin removal, and customer confirmation. Store the source system and native timestamp for every event. If two systems disagree, retain both times and mark the discrepancy rather than choosing the tidier sequence.
The chronology distinguishes an asserted fact from observed evidence. “Our founder left” is a requester assertion. A directory entry showing the founder’s account was disabled is system evidence. An agent note saying identity was checked is not the same as a recorded authentication event. This distinction matters because a fluent narrative can hide that the decisive control occurred off-platform or was never documented.
Access to the research table should be limited. Names, email addresses, identity documents, recovery codes, and message contents are not needed in an analyst’s reusable dataset. Replace tenant and user identifiers with study keys, keep the linkage table separately, and record only the minimum attributes needed to evaluate the control path.
Code authority separately from identity
Identity answers who is making the request; authority answers whether that person may control the tenant. The codebook must not collapse them. A requester may prove control of a personal email account without proving that an employer authorized a transfer. Conversely, a corporate officer may have authority but still need to authenticate through an approved channel.
For each case, researchers should code the strongest authority evidence actually reviewed: approval from a current administrator, an established tenant-owner workflow, verified organizational records, a contractual contact, a court or insolvency document, or another policy-defined route. Record “not visible” when the decision references evidence held outside the reviewable systems. Do not convert missing evidence into a failed check or assume that a familiar company domain establishes authority.
NIST SP 800-53 treats access enforcement, account management, separation of duties, and audit records as related controls rather than interchangeable paperwork. That framing supports testing both the entitlement decision and its technical execution (NIST SP 800-53 Rev. 5). OWASP likewise recommends validating authorization on every request and denying access by default; for this study, that means an undocumented exception cannot be coded as a normal approval simply because the account change succeeded (OWASP Authorization Cheat Sheet).
Examine authentication at the moment of recovery
Researchers should identify which authenticator was used, when it was used, and whether the event occurred before the privilege change. A password login, possession of an existing session, control of an email inbox, and successful multi-factor authentication are materially different observations. If a support agent used a live call or manual document review, the dataset should name that method without storing the sensitive artifact.
NIST’s authentication guidance distinguishes authentication assurance and emphasizes protections around authenticator binding and recovery. The protocol should therefore code recovery as its own pathway instead of treating it as equivalent to a routine login (NIST SP 800-63B). A case in which the same compromised mailbox receives both the reset link and the administrator invitation should be visible as a shared-channel dependency.
Record step-up failures and abandoned attempts. Excluding them would make the control appear smoother than customers experienced and would erase attempted changes stopped by the system. Failed identity checks should not reveal secret answers or document details in the analytical copy.
Identify takeover signals without declaring guilt
The study should test whether reviewers saw relevant warning signs before approval. Candidate signals include a recent password reset, new device or location, changed billing contact, newly created email domain, disabled former administrator, burst of failed logins, simultaneous export activity, unusual API-token creation, or contradictory statements about ownership. These are review prompts, not proof of an attack.
Create three codes: signal absent, signal present, and signal unavailable. “Absent” is appropriate only when the underlying telemetry was checked and contained no defined signal. If logs were not retained or the reviewer lacked access, use “unavailable.” Researchers should record whether a present signal caused escalation, additional authentication, a delay, or no visible action.
CISA describes identity and access management as the policies and technologies used to ensure the right users receive appropriate access. That broad control objective supports examining joiner, mover, and leaver conditions around an admin change, rather than reviewing the support conversation alone (CISA Identity and Access Management). The study should not imply that CISA endorses a particular vendor workflow.
Verify the privilege event and its aftermath
An approval is not proof of correct implementation. Match the decision to the product audit event that created, elevated, demoted, or removed the account. Capture the actor, target, role, tenant, event time, and event identifier where the platform exposes them. A mismatch between the approved email and the granted account is a control failure even when the ticket is marked solved.
Then inspect a bounded follow-up window for protective actions required by policy: revocation of the former administrator, termination of active sessions, rotation of recovery contacts, notification to other administrators, or a temporary restriction on destructive actions. The study should report each action separately. A composite “secure change” label is useful only if its components and missing-data rule are published.
Cases involving multiple administrator roles require special care. A billing administrator may not have permission to manage identity providers; a workspace owner may differ from an organization owner. Researchers must map the requested business authority to the actual product entitlement rather than comparing role names as strings.
Measure process performance without rewarding unsafe speed
Timing begins when the first identifiable admin-change request enters a supported channel. Report time to first response, time to a documented authority decision, and time from approval to the product privilege event. Pause periods should remain in elapsed time but may also be reported separately when the team was waiting for customer evidence. Publishing both prevents an internal “active handling” clock from disguising a long customer wait.
Do not rank agents by raw approval speed. Complex succession, acquisition, or deceased-owner cases legitimately take longer than changes approved by a current administrator. Stratify descriptive results by pathway and risk-review status. Show medians and distributions only if the final cohort is large enough to avoid exposing individual tenants. Small cells should be suppressed under a rule chosen before analysis.
The analysis can compare the share of cases with complete identity, authority, risk-review, and audit-event evidence. It may describe associations between pathways and completion times, but it cannot infer that a queue, staffing level, or authentication method caused a better outcome. Tenant size, contract tier, incident severity, and missing telemetry may influence both routing and resolution.
Test reviewer agreement on difficult cases
Two trained reviewers should independently code a sample that deliberately includes approved, rejected, unresolved, and security-escalated requests. Agreement should be measured separately for authority evidence, authentication pathway, takeover-signal availability, and correct privilege implementation. A single overall percentage could conceal disagreement on the most consequential field.
Resolve disagreements through a recorded adjudication process. If reviewers repeatedly disagree because the policy itself is ambiguous, revise the codebook and recode the affected sample; do not merely instruct one reviewer to follow the other. Preserve the pre-adjudication values so the final report can distinguish improved guidance from apparent agreement created after discussion.
Within-case contradictions deserve their own log. Examples include an approval timestamp after the role grant, a ticket saying the former admin was removed while the audit log shows continued access, or a security note referencing telemetry unavailable to the research team. These cases should remain in denominators and be reported as evidence conflicts.
Run sensitivity checks and bound the conclusion
Repeat key summaries under at least two missing-evidence rules: one that treats unavailable control evidence as incomplete and another that reports it separately. Recalculate implementation accuracy after excluding cases where the product audit log had already expired. Compare results with and without emergency changes. If the conclusions shift materially, the report should foreground that instability.
The study package should contain the cohort query, deduplication rules, field dictionary, codebook versions, reviewer training notes, disagreement table, analysis script, and a dated limitations memo. It should also document log-retention boundaries and any systems the researchers could not access. Another qualified analyst should be able to reconstruct every aggregate without receiving identity documents or customer message content.
A defensible conclusion will be narrow: the observed records either do or do not demonstrate the defined controls for the sampled requests. The study can identify where evidence disappears, where authority and identity are confused, and where approved intent diverges from the product event. It cannot establish that every approved requester was legitimate, prove that an unavailable signal was absent, or claim that the reviewed workflow prevented account takeover. Those limits are part of the finding, not a footnote to remove.