How is a cloud account created?¶
A cloud account can begin with a person filling in a sign-up form, an administrator creating a work identity, an invitation from another organisation or an automated feed from an existing directory. The route matters because it determines who made the account, what they supplied and where the creation evidence is likely to sit.
Four accounts can look similar after sign-in¶
Dave appears as a named user in four services. That does not mean all four accounts began with Dave typing his details into four registration pages.
Begin with the creation route. “The account belongs to Dave” is too compressed if an administrator, invitation or synchronisation process actually produced it.
Turn the route into a creation chain¶
Suppose the relevant account is dave@northstar.example. Northstar says it is Dave's work account. The useful next question is: what system first made that identity appear?
| Creation route | Recognisable artefact | Who may hold the explanation? | What to compare next |
|---|---|---|---|
| Personal sign-up | Creation time, verified address or telephone number, recovery details, initial device or network context | Cloud provider and the person controlling the supplied identifiers | Verification message, payment, device and earliest sign-in |
| Admin-console creation | Administrative audit event, new-user profile, initial password delivery and service-desk request | Organisation and provider | Creating administrator, HR record, ticket and first user sign-in |
| External invitation | Invitation event, inviter, invited address, guest/member type and acceptance state | Inviting organisation, home identity provider and recipient | Invitation message, acceptance event and later access |
| Directory provisioning | Source directory object, connector or synchronisation event and cloud object | Organisation's identity, HR and cloud administrators | Source record, mapping, provisioning logs and assignment date |
| Linked identity | Provider account ID plus the external identity used to authenticate | Both services, depending on the design | Identity-provider sign-in and the relying service's account event |
The creation chain should preserve both ends. If an HR system supplied Dave's staff record to a directory, and the directory then provisioned Google Workspace, recording only “Google account created” loses the source that explains why it appeared and who authorised it.
A concrete Microsoft Entra creation record
Microsoft Graph describes createdDateTime as the automatically populated UTC time when the Entra user object was created. It describes id as the user's unique, opaque directory identifier and userPrincipalName as the Internet-style sign-in name.
The creationType property can distinguish routes including an external invitation, email-verified self-service sign-up and a self-service user flow. A normal school or work account can have a null creationType, so the absence of a label does not mean the account has no creation history.
Microsoft also documents administrator creation, external guest invitation and users added by synchronising existing on-premises directory data. These are different origins with different records to follow.
A concrete Google Workspace creation route
In a domain-verified Google Workspace environment, an authorised administrator can add a user in the Google Admin console under Directory > Users. The current form includes a primary email address and can include a secondary email, telephone number, organisational unit and initial password arrangements.
For an enquiry, the significant point is not the sequence of buttons. It is that the organisation may hold the allocation record and Google Admin log events can identify an administrative actor, event, affected resource and relevant old or new values. A welcome message or service-desk ticket may connect the created profile to the intended recipient.
Write a conclusion that keeps the chain intact¶
A useful account-origin statement might be:
Northstar's administrator Priya created
dave@northstar.examplein Google Workspace after service-desk ticket HD-1842 allocated the account to Dave. The creation and allocation establish the account's organisational origin. Dave's control of the later file event must be tested through the corresponding sign-in, device and activity records.
That statement extracts positive value from the creation evidence without pretending it proves later use.
The point to remember
Do not merely ask when an account was created. Establish whether it was self-registered, administrator-created, invited, provisioned or linked; then follow the record and actor responsible for that route.