Answering the Cyber Insurance Admin Accounts Question

To answer a cyber insurance admin accounts question, read the exact form in front of you, export who actually holds administrator rights, and report only what that evidence shows today. Forms vary. Separate administrator identities, MFA, local administrator restrictions and privileged access management (PAM) are distinct facts, and one does not establish the others. "Our IT provider handles that" is not an answer, because the provider's identities and privileges belong in the same inventory.

If wording or scope is ambiguous, ask your broker or carrier in writing before signing. This is not legal advice, and no answer, remediation plan, product or account count guarantees eligibility, pricing, coverage, renewal, limits or claim payment.

What do carrier forms actually ask about admin accounts?

They ask different things in different words, so answer the form you have. The two examples below show what those versions of those forms ask, not a universal rule or the current question for every applicant.

The Corvus Smart Cyber Insurance Application, Version 3.2, September 2024, question 12 asks, "How are privileged accounts secured and managed? (Please select ALL that apply)" and lists these separately:

• "Administrative users use different accounts for administrative use and non-administrative use (e.g. day to day activities such as web browsing and email)"
• "Local administrator accounts are unique and complex on all systems"
• "A password management vault is used to manage privileged accounts"
• "Standard users do not have administrative rights to their workstations"

Its question 11 separately asks about MFA "to secure internal use of privileged accounts (administrator accounts, service accounts, etc.)".

The At-Bay Cyber Ransomware Supplemental Application, form AB-CYB-RWS 09/2025, splits the same territory differently:

• Question 10 asks where MFA is deployed, including "Privileged and administration accounts".
• Question 11 asks how the applicant controls privileged access for employee workstations: all employees have administrator privileges, IT only with one set of credentials, or IT only with separate administrative and non-administrative credentials.
• Question 12 asks whether the applicant uses no PAM solution, uses PAM to control access to privileged credentials, or uses PAM for that plus monitoring of privilege use.

Note the scope. At-Bay's question 11 is about employee workstations, so it does not describe who holds tenant-wide roles. Its signature block also has an authorized representative declare, to the best of their knowledge and belief and "after reasonable inquiry", that the statements are true and complete. Checked evidence is the practical way to prepare for that signature.

Who counts as an administrator for this question?

Count anyone or anything that can change security settings, identities, permissions, systems or recovery controls. If your form defines privileged accounts, start from its definition and confirm any gap in writing.

Inventory at least these:

• Microsoft 365 or Microsoft Entra tenant roles such as Global Administrator
• Google Workspace super administrators and delegated administrators
• Active Directory or domain, server, hypervisor, database, network, firewall and backup administrators
• Endpoint, RMM, MDM and security-tool administrators
• Outside IT provider or MSP identities, named and shared, including any left by a former provider
• Service and other non-person accounts whose actual rights are elevated
• Emergency or break-glass accounts

Service and emergency accounts need separate review because interactive MFA and daily-use rules may not apply to them in the same way. A service account is not privileged merely because it is a service account; include it when its rights are elevated, and record exceptions instead of giving a blanket yes.

An IT provider running your systems establishes no control by itself. Ask for a roster of provider identities, roles and systems, then verify it against your own exports.

What does a separate admin account mean?

A separate admin account means the everyday email and web identity holds no standing administrative rights, and administrative work uses a different identity or role. Two usernames prove nothing if both keep the same privilege or the everyday account can still administer the environment.

Check the everyday account's role assignments and group memberships directly. The technical reason is scope of damage: Microsoft's least-privilege guidance contrasts malicious code opened under a domain administrator account with the same code opened under a normal user account. CISA likewise advises using a standard account for day-to-day work. Those are security recommendations, not insurance requirements.

Why are separate accounts, MFA and PAM different questions?

They describe different controls, so a yes to one is not evidence for another. Separation limits where elevated privilege is used, MFA adds a factor where it is actually enforced, and PAM concerns how privileged access is controlled and observed.

• MFA: enforcement needs its own evidence by account group, covered in answering the MFA section of an application.
• PAM: NIST's archived NCCoE project describes it as a domain within identity and access management "that focuses on monitoring and controlling the use of privileged accounts", including local and domain administrative, emergency, application management and service accounts. The project is archived and oriented to financial services, so use it for the concept only.
• PAM products: tools may control, broker, vault, rotate, approve, monitor or audit privileged access. Capabilities vary, so describe what yours does.

Not every small company must buy a PAM product. At-Bay's question 12 includes "Applicant does not use a PAM solution" as a choice, and an honest no can sit beside documented other controls.

What about local administrator rights?

Local administrator membership on one workstation is narrower than tenant-wide, domain-wide, network, backup or server administration. It still counts when the form asks about privileged accounts or workstation administrator rights, so report it as its own finding.

"Standard users do not have local admin" does not prove organization-wide administrators are controlled, and the reverse is also true. Microsoft warns that local Administrators membership on a workstation carries elevated risk even with UAC enabled, and that reusing the same local credentials across machines exposes them to pass-the-hash attacks. Corvus lists unique and complex local administrator accounts as its own item, so verify that separately too.

Evidence checklist for the admin accounts answer

Keep one record per account or assignment:

• Account identifier and human or system owner
• Platform or system
• Assigned role or group and actual scope
• Type: human, shared, service or emergency
• Relationship: employee, contractor, MSP, former provider or vendor
• Whether daily-use and admin identities are separate
• MFA enforcement and any documented exception
• Local administrator group membership or endpoint elevation mechanism
• PAM, vault, approval or monitoring facts, if any
• Last successful use or sign-in, and whether the account is still required
• Evidence source, collection date, reviewer, exception owner and last access-review date

Useful artifacts include role exports, group membership exports, conditional-access or MFA reports, a local administrator inventory, firewall, backup and RMM admin lists, a provider access roster, a vault or PAM export if used, tickets and an approved exception register. A policy statement alone does not prove current configuration.

Fictional worked example

This example is invented. A 60-person company discovers seven Global Administrators, including two accounts belonging to its former IT provider. The owner's everyday account also holds Global Administrator.

Defensible present-tense answer: "The Global Administrator export reviewed for this application shows seven current assignments. Two belong to a former IT provider and remain assigned, pending urgent ownership and disablement review. The owner's daily account also holds this role, so daily use and administration are not separated for that account. MFA enforcement, service and emergency accounts, local administrator rights and other systems have not yet been verified."

On a select-all form, that finding means the separate-accounts option should not be selected on the strength of intentions. Ask the broker how to record a partial state.

Planned remediation, not complete: "We will confirm ownership and dependencies of the two former-provider accounts, then remove their access. We will create a separate administrator identity for the owner, confirm recovery access, then remove the role from the daily account. Each item has a named owner and target date."

Do not describe that cleanup as finished until it is. Do not disable emergency or service accounts blindly either: validate dependency, recovery and access first.

Fill-in response template for the application

• Exact application question and form or version:
• Scope and interpretation confirmed with broker or carrier, if needed:
• Verified configuration and platforms reviewed:
• Counts by account and role type:
• Separate-account usage:
• MFA enforcement and exceptions:
• Local administrator findings:
• Provider access:
• PAM or other privileged-access controls actually used:
• Evidence date and reviewer:
• Exceptions and open items:
• Planned improvements, owner and target date (future work, not current state):

Related application guide

Administrative privilege and remote connection paths are separate facts. Use the RDP and remote access application guide to inventory VPNs, gateways, vendor tools, public exposure and MFA before answering how people reach those accounts.

An administrator inventory identifies who has power; it does not prove those actions are centrally visible. Use the SIEM and logging application guide to verify which identity and administrator events are ingested, retained and monitored.

Sources

• Corvus Smart Cyber Insurance Application, Version 3.2, September 2024
• At-Bay Cyber Ransomware Supplemental Application, AB-CYB-RWS 09/2025
• NIST NCCoE, Privileged Account Management for the Financial Services Sector (archived project)
• Microsoft, Implementing Least-Privilege Administrative Models
• CISA, Implement User Account Control to Protect Your Personal Computer