The “Who Logs In?” Audit: Untangling Super-Admin Rights vs. Billing Contact Rights on Client Software

Picture a composite scenario. It is 2:15 PM on a Tuesday, and your agency gets an urgent call from a high-value client. Their customer portal or e-commerce stack has started throwing authentication errors, and operations have stalled.

Your senior developer finds the cause within minutes. A third-party subscription the site depends on lapsed after a failed card renewal. They open the vendor’s console to update the card or retry the charge and hit a wall: “Insufficient Permissions.”

The vendor’s warning emails over the previous weeks went to a former marketing coordinator who left eight months ago. Nobody on the client’s current team saw them. Your developer has technical access but no billing access. The client’s executives are asking why the site is down, and your agency is the one answering.

This is not a code defect. It is an account governance failure. Agencies routinely fall into the gap between Super-Admin rights (who can configure the system) and Billing Contact rights (who can pay for it, and who gets told when payment fails). A short, repeatable “Who Logs In?” audit closes that gap before it becomes an outage.

1. Why Super-Admin and Billing Rights Get Confused

Most serious platforms separate technical administration from financial administration, and the split is deliberate. The trouble is that the separation is rarely visible during signup, so clients and agencies each assume the other side has the access.

 +---------------------------------------------+ | ACCOUNT OWNER / PRIMARY CONTACT | | (client-controlled; root or owner identity)| +----------------------+----------------------+ | +------------------+------------------+ | | v v +-------------------------+ +---------------------------+ | TECHNICAL ADMIN ROLES | | BILLING / FINANCE ROLES | | (agency engineers, | | (client finance or ops) | | delegated access) | | | +-------------------------+ +---------------------------+ | - API keys, webhooks | | - Payment methods | | - Deployments, config | | - Invoices, receipts | | - User and team access | | - Plan and tier changes | | - Integrations | | - Billing notifications | +-------------------------+ +---------------------------+ | | +------------------+------------------+ v +-------------------------------+ | THE GOVERNANCE GAP | | Alerts reach people who can't | | act; people who can act never | | see the alerts. | +-------------------------------+ 

How major platforms actually draw the line

The details differ by vendor, which is why a per-tool audit beats a general assumption.

• AWS: By default, IAM users and roles can’t access the Billing and Cost Management console, even if their IAM policies grant billing permissions. The root user has to turn on “Activate IAM Access” first. An agency engineer with full administrator permissions can therefore be locked out of invoices and payment settings.
• Google Cloud: The Billing Account Administrator role manages payment methods, exports, and project links. Google’s own documentation notes that Project Owner and other resource-level admin roles don’t grant the permissions needed to see basic billing account information. Only Billing Account Administrators can contact Cloud Billing Support, and the person who creates the billing account is an administrator by default.
• Stripe: The Super Administrator role goes to the creator of a business account. There can be only one Account Owner per account, and only the owner can transfer ownership.
• Shopify: Changing the plan requires the store owner or a staff member with the “Manage plan” permission. Bills are emailed to the store owner and to any staff with the “View billing and receive billing emails” permission.

The common thread is that the person who signed up usually becomes the owner with the broadest rights. Every later handoff, from that person to the agency or to a new employee, is where billing visibility is lost.

The two classic onboarding mistakes

1. The “Hand Over the Keys” mistake. The client gives the agency the original owner’s login. When that employee leaves and IT deactivates their mailbox, the account’s recovery email, MFA prompts, and billing notices can disappear with it.
2. The “Developer as Vendor” mistake. The agency creates the account under a developer’s work email and enters the client’s card. When that developer leaves the agency, the client doesn’t hold the identity that owns their own infrastructure.

2. How the Blame Lands on the Agency

These are composite, illustrative scenarios, not reports of specific incidents. Each reflects a documented permission model.

Scenario A: The ghost inbox

A client’s former operations manager signed up for a third-party service with her individual work email. After she leaves, IT removes the mailbox. The client replaces its corporate card, the next renewal fails, and every payment-failure notice goes to an address nobody reads.

How severe the outcome is depends on the vendor. Some providers suspend features, some downgrade the plan, and some stop service entirely. A real example of the severe end is Google Cloud. If a Cloud Billing account is suspended, all resources attached to it are suspended as well, and if it stays invalid for a protracted period some resources might be removed and are not recoverable. Google’s own restart guidance adds that when a billing account is closed, all billable services in all linked projects are stopped, and some resources might be deleted and not fully recoverable. Many customers resolve a suspension without losing anything, but the guidance is why a lapsed billing contact matters.

The site breaks, the client sees “broken,” and they call the agency.

Scenario B: The administrator who can’t see the bill

Your engineers have administrator access to the client’s AWS account. A usage spike or an expiring payment method needs attention, and nobody on your side can open the billing console, because the root user never activated IAM access to billing. In Google Cloud, the equivalent is an engineer who is a Project Owner but holds no billing role. The engineer can fix the code but can’t see an invoice, change a payment method, or reach billing support.

Without a named financial escalation contact, the fix waits for someone on the client side who is out of reach. The agency still gets the blame for the outage.

3. Step-by-Step: Running the “Who Logs In?” Audit

Make account governance a standard, billable part of onboarding and maintenance. The audit has four stages.

 THE 4-STAGE GOVERNANCE AUDIT +---------------------------------------------+ | 1. INVENTORY & MAP | | Every SaaS, API, domain, and service | +----------------------+----------------------+ v +---------------------------------------------+ | 2. AUDIT ROLES & CONTACTS | | Owner vs. technical admin vs. billing | +----------------------+----------------------+ v +---------------------------------------------+ | 3. DECOUPLE & DELEGATE | | Role-based inboxes, vaults, delegation | +----------------------+----------------------+ v +---------------------------------------------+ | 4. DOCUMENT & FORMALIZE | | Access matrix + contract language | +---------------------------------------------+ 

Stage 1: Map the software inventory

List every third-party service the project depends on, including small ones like transactional email, search, and form tools. For each, record who owns the account, who receives billing notices, and who holds technical access.

The table below is an illustrative example with placeholder addresses.

Flag any row where the owner or billing contact is a departed person or an agency employee.

Stage 2: Audit roles and permitted actions

For each service, answer four questions:

1. Who receives payment notifications and invoices? It should be a monitored role-based inbox, not an individual’s address. On AWS, check the alternate contacts for billing, operations, and security. AWS’s own baseline guidance recommends email distribution lists for these contacts and notes that you must retain access to them.
2. Who holds the owner or root identity? It should be a current employee of the client, tied to a client-controlled domain.
3. Can the agency do its technical work without holding payment liability? Delegated roles should cover this.
4. What is the MFA recovery path, and does it depend on one person’s phone? Check this before the person leaves, not after.

On that last point, the standards have moved. AWS ended support for enabling SMS-based MFA. It now enforces MFA for root users on all account types, and it lets root and IAM users register up to eight MFA devices, so a lost phone doesn’t have to mean a lockout. NIST’s SP 800-63B-4 classifies SMS and other PSTN-based out-of-band authentication as a restricted authenticator. It remains permitted, but the implementing organization must assess and accept the risk. An owner account whose only second factor is a departed employee’s SMS number is a governance failure waiting to happen.

Stage 3: Decouple and delegate

Keep financial identity with the client and technical delegation with the agency.

• Rule 1: The client owns the subscription. The client should hold and pay for its own software accounts. Agency-held accounts billed to an agency card and passed through on invoices can create billing friction and ownership disputes when the relationship ends.
• Rule 2: Use role-based addresses. Use shared aliases such as saas-billing@clientcompany.com for billing, and dev-alerts@agency.com on the agency side for technical alerts. Individual mailboxes should not be the contact of record for billing or recovery.
• Rule 3: Delegate access, don’t share logins. Use each platform’s built-in delegation instead of passing around the owner’s password. Examples:
  • Microsoft 365 partners: Granular delegated admin privileges (GDAP) give partners specific, time-bound access, in place of the older DAP model that granted broad standing access. GDAP relationships have a defined end date, with a maximum of two years, so put the expiry on your calendar.
  • Shopify: Give agency staff only the permissions they need and leave the billing and payment permissions with the client.
  • AWS: Prefer identity federation with IAM Identity Center over shared credentials. AWS recommends this as a security best practice.
  • Google Cloud: Grant the narrow billing roles that fit the task. The Project Billing Manager role, for example, can link a project to a billing account without granting any rights over resources.
• Rule 4: Use a password manager for what can’t be delegated. Where a service offers no delegated roles, store shared credentials in an encrypted vault such as 1Password, Bitwarden, or Keeper, never in chat or email. Rotate secrets whenever someone with access leaves.

Stage 4: Document and formalize

Publish the access matrix from Stage 1 to both sides and attach it to the contract. Every row should name an owner, a billing contact, a technical contact, and a backup. Review it on a schedule.

4. Contractual and Operational Protection

An audit tells you where the gaps are. The contract decides who pays when one of them breaks something.

Put ownership and payment responsibility in the agreement

Add language to your Master Services Agreement or Statement of Work that states where responsibility sits. A sample you can adapt:

Third-Party Services and Account Ownership. Client retains ownership of, and responsibility for payment of, all third-party software, APIs, hosting, and SaaS subscriptions required to operate the application, and shall maintain current, monitored billing and security contacts for each. Agency is not responsible for service interruptions resulting from lapsed payment methods, unmonitored billing contacts, or access changes made by Client or the third-party provider.

Have a qualified attorney review any limitation-of-liability language. Enforceability varies by jurisdiction, and this sample is not legal advice.

Define an emergency escalation protocol

When a payment fails and a tool goes down, speed matters. Agree on the following in writing before an incident:

1. A named financial escalation contact on the client side, with the authority and the platform role to approve payments. On Google Cloud, for example, that means someone who holds the Billing Account Administrator role, since only those administrators can contact Cloud Billing Support.
2. Pre-authorized limits. State whether the agency may temporarily cover an unpaid third-party bill up to a set amount (for example, $250) to prevent an outage, with reimbursement guaranteed by the client.
3. A response clock. Specify how quickly the client contact must respond, and who stands in when they’re out of reach.

5. Checklist: The “Who Logs In?” Framework for Onboarding

Use this when onboarding a client or launching a major project:

• Ownership verified: Every account is registered under a client-controlled domain, not an agency address or a contractor’s personal email.
• Billing routing confirmed: Invoices, failed-payment alerts, and card-expiry warnings go to a monitored role-based alias.
• Billing access mapped: Someone with real billing permissions is named for each service, using that platform’s own roles (for example, an AWS root user who has activated IAM billing access, or a Google Cloud Billing Account Administrator).
• Technical access delegated: Agency developers use individual, delegated credentials with technical permissions only, not shared owner logins.
• MFA recovery verified: Owner accounts have more than one registered MFA method where the platform allows it, preferably passkeys or security keys. No account depends on one person’s SMS number.
• Backup owner assigned: At least two active client stakeholders can administer each critical account. Where a platform allows only one owner, as Stripe does, a second Super Administrator fills the gap.
• Delegation expiries tracked: Time-limited relationships, such as Microsoft GDAP, have renewal dates on the calendar.
• Review scheduled: Access lists, billing contacts, and departed-user clean-up are reviewed every 90 days.

Conclusion: Turning Governance into a Value-Add

Billing contacts that nobody reads and permissions that don’t match responsibilities are a silent risk to any production site. Vendors such as AWS, Google Cloud, Stripe, and Shopify already offer the separation of duties you need. What they can’t do is make sure the right person holds each role when something fails.

Running a “Who Logs In?” audit at onboarding, and again every quarter, protects your team from blame it didn’t earn and gives clients a clear picture of who owns what. It also positions your agency as the partner that treated account access as part of the engagement.

Originally published at https://instarenewal.com/blog/the-who-logs-in-audit-untangling-super-admin-rights-vs-billing-contact-rights