Blog · Licence guides
Credential creation, handover and access
Updated 5 September 2026 · Based on our Software Licence & Services model
Why infrastructure accounts should be in your name, what you must secure at handover, and how temporary access works for later fixes.
What this means for you
Where practical, cloud and vendor accounts are registered with an email, phone, legal identity and billing method controlled by you. At handover you should change temporary passwords, verify recovery contacts, enable MFA/passkeys, secure recovery codes and review admin access.
After handover, LMS White removes or relinquishes Owner/Super Admin access unless you expressly authorise continuing delegated access. We do not need permanent possession of your master passwords. For later upgrades or fixes, you grant temporary, least-privilege access only to systems required for the work — then rotate credentials if a master password had to be shared.
Why this model exists
If the vendor forever holds your Owner credentials, you never truly control your student data plane. If nobody documents handover, disputes arise about who was responsible when an ex-employee still had access. Temporary delegated access is the industry-standard way to let a vendor maintain software without owning your cloud forever.
Examples
- Firebase/Google Cloud project created under your Google Workspace → you own billing and IAM after go-live.
- For an iOS rebuild, you invite LMS White as a limited App Store Connect role instead of emailing the Apple ID password.
- Parties may sign a Credential & Infrastructure Handover Certificate as evidence of the handover date.
What LMS White controls: how we request least-privilege access for agreed work.
What you control after handover: MFA, staff offboarding, recovery codes and who remains an Owner on your vendor accounts.