Who should own the Azure tenant when someone else builds your system

Ownership is not one decision. It is about ten of them, taken at different moments by different people, usually without anyone writing them down. For each row below, name the legal entity on the account and the person at the client who could sign in today without asking the builder for anything.

The order matters. Password recovery for nearly everything under the registrar record runs through an address at that domain, so whoever controls the domain can receive a reset mail for the source control organisation, the payment account and the app store account. The cloud tenant is the exception worth engineering deliberately, since an emergency access account on the tenant's own onmicrosoft.com domain depends on neither the domain nor its mail routing.

There is a legitimate version of the arrangement. A law firm's practice manager is not going to administer conditional access policy, and pretending otherwise produces a tenant nobody looks after. What separates the sound version from the bad one is custody: the account is created in the client's legal entity name, with the client's billing instrument and the client's emergency access credentials, and the builder works inside it under identities the client can switch off.

The signs of the other version are checkable in an hour. The registrant contact on the domain is an address at the builder's domain. The subscription sits under the builder's agreement with the cloud provider, so there is no billing account for the client to sign in to. The repository lives in an individual's personal account. The app store enrolment runs under the builder's business identity, so the listings and the signing certificate belong to the builder's legal entity. The version that cannot be repaired later is the shared tenant, where the client's resources sit in a subscription carrying other clients' work: isolation is a naming convention, and there is no clean export, because the unit that moves between directories is a subscription the client owns a fraction of.

Two models let a builder work at arm's length without holding the directory. Under a reseller arrangement the client keeps its own tenant while the partner is reseller of record with delegated administrative access, and Microsoft has moved partners off standing directory-wide delegation onto granular grants that expire, so ask which of those is in place and what ends it. Azure Lighthouse is the other: the client delegates named scopes to the builder's tenant against specific roles, the builder's engineers sign in with their own credentials, the work appears in the client's own activity log, and the client can withdraw the delegation without the builder's involvement.

For an APRA-regulated client the paperwork is explicit. CPS 230 commenced on 1 July 2025, and for contracts already in place it applies from the earlier of the next renewal or 1 July 2026. Core technology services must be classified as a material service provider arrangement unless the entity can justify otherwise, which puts the builder on the register the entity submits to APRA each year, and the formal agreement has to set out ownership of assets, ownership and control of data, audit access and termination rights. Those clauses are difficult to answer honestly when the builder holds the directory.

Each of the builder's engineers gets an identity of their own in the client's directory, either as a member on the client's domain or as a guest invited from the builder's tenant. Both of those are defensible. A shared developer login with the password in the builder's password manager is not, because a log entry recording that a change was made by developer@ answers nothing when the question is which of six people made it and whether that person still works there. Guests carry a practical advantage, since the object lives in the client's directory where it can be reviewed and disabled, while authentication happens against the builder's directory, so the builder's own offboarding removes the underlying account.

The roles attached are the part worth arguing about. Standing Owner on a subscription and standing Global Administrator in the directory should never be permanent, and both can be replaced with elevation on request that expires by itself. The deployment pipeline is where standing credentials hide: a pipeline authenticating with a client secret held in the build system carries a long-lived credential the client cannot inspect, and nobody rotates it because rotating it breaks deployments. Workload identity federation removes the secret, since the app registration trusts tokens issued by the pipeline for a specific repository and branch, and the client can break that trust in one action.

Scope the pipeline's role assignments to the resource groups it deploys into, and keep the identity that deploys separate from any identity that can read production data. A named person at the client then reviews access quarterly against the actual role assignments rather than against the contract, and access is removed the week an engineer rolls off rather than at the end of the engagement. Conditional access should require phishing-resistant multi-factor authentication for the builder's accounts specifically, because a contractor's laptop sits outside the client's device management and the compliant-device signal will not be there to lean on.

Where the only administrators in a tenant are the builder's staff, the client's ownership stops at the paperwork. The working pattern that fixes it is two cloud-only accounts on the tenant's own onmicrosoft.com domain, depending on neither federated sign-in, nor the client's domain, nor mail delivery that may itself be the thing that has broken, and excluded from the conditional access policies that could lock them out.

Exclusion from conditional access is no longer enough on its own. Microsoft enforces multi-factor authentication on sign-ins to the Azure portal and the admin centres at the application level, outside conditional access, so an emergency account carrying only a long password fails at the moment it is needed. Register a phishing-resistant method on each one, a passkey or certificate-based authentication, and check the account is not caught by a self-service password reset policy that will demand a mobile number nobody wants attached to it.

The credentials belong to the client and are held by a named person there, ideally split so that no single person can use one alone, with the password held by one director and the hardware key by another. Where the builder holds them for safekeeping, the arrangement has quietly reversed itself. Use has to be visible without the builder's cooperation, so alert on any sign-in by either account to a client mailbox rather than only to the builder's monitoring. Test both quarterly, because untested emergency accounts fail precisely when they are needed: credentials expire, a stale-account cleanup disables them, or a new policy catches them despite the exclusion.

Most handover documents describe how the system works. The pack that matters proves who controls it, and the difference shows up in the first hour of the first incident after the builder has gone, when the live question is not how the caching layer works but which credential renews the certificate and who is on the notification list for it.

The register at the top of the list takes the least time and matters most, because it can be written at any point in the engagement and it makes the gaps visible while there is still a working relationship in which to close them. The row where the legal entity column carries the builder's company name is a conversation better had during the build.

The rows in the register are worth checking rather than trusting. Book an afternoon, tell the builder you are running it, and work through the sequence below using only credentials the client already holds. Each step either passes or names precisely which asset is not yours.

Failures are not evenly weighted. Cloud resources are recoverable while you hold the tenant, because you can remove access and keep running. The assets that become leverage in a bad ending are the ones with a third party and a human process in the middle: the domain registrant record, the app store account holder, the merchant account and the code signing identity. Each of those needs the counterparty's cooperation or a formal process measured in weeks. Section 286 of the Corporations Act 2001 also requires seven years of financial records, and records held inside somebody else's account are records you are trusting somebody else to keep.

The domain is the hardest to recover. A .au name is licensed rather than owned, and the licensing rules are explicit that the licence creates no proprietary interest in the name, so there is no property to claim back. A transfer begins with a written request from the current registrant to the registrar, and the incoming registrant has to satisfy the Australian presence and eligibility rules in its own right, which means whoever occupies the registrant field decides whether the name moves at all. The .au dispute resolution policy exists, but it is a filed administrative proceeding in which the complainant has to establish rights in the name, that the registrant has no legitimate interest in it, and bad faith in the registration or the later use, and that is a harder case against a developer who registered the name at your request than against a squatter. Run the test in the first month of a build. A failed step at that point is an email to the builder, and the same failed step after the relationship has ended is a negotiation with someone who no longer needs your goodwill.

We work inside the client's tenant, under named identities, on accounts registered to the client, and the register gets filled in before anything is built on top of it. Retrofitting custody onto a live estate is the expensive path and the one that gets deferred indefinitely. Our engineers hold roles that expire, the client holds the emergency access credentials, and sign-ins by those accounts alert to a client mailbox.

The reasoning matches the systems we build. The operations and compliance portal we built and run for GRM LAW, a Brisbane law firm, covers intake, conflicts checks, the matter register and AML/CTF readiness over an append-only audit ledger. The staff portal we built for Stone Leaf Capital carries a compliance audit log capturing actor, action, and before and after state. Aurii, our own clinical software venture, is Australian-hosted on Azure with tamper-evident audit trails. In each case the record has to be readable by the organisation that has to answer for it.

Where an estate has already drifted, the work starts as an assessment rather than an argument. An Azure and Entra ID security review establishes who actually holds what: standing role assignments, service principals carrying credentials nobody rotates, delegated partner access, guest accounts from directories that no longer exist, and resources created outside any pipeline. It ends with the account register filled in and an exit test the client can run without us. Ask any builder, including this one, to put that register in the proposal.