Privacy Policy

Service: MIE Auth (https://auth.mhglobalgroup.com)

Last updated: 1 August 2026

This notice explains what personal data MIE Auth collects, why we collect it, how long we keep it, who else sees it, and the rights you have over it. It is written to be read: each dense section opens with a short plain-English summary, and every operational statement in it describes what the service actually does today.

1. Who we are and how to contact us

MIE Auth is an authentication service operated by MH Global Group Limited, a company registered in England and Wales under company number 16317481, whose registered office is at 16 St. Clare Street, London, England, EC3N 1LQ. MIE Auth is the name of the service; MH Global Group Limited is the legal person behind it and the data controller for the purposes of this notice. In this notice, 'we', 'us' and 'our' mean MH Global Group Limited; 'you' means the individual whose personal data we process. MIE, including MIE Pathways and MIE English Academy, is a brand of MH Global Group Limited; where the service or its home page refers to 'MIE Group', that means MH Global Group Limited.

Privacy enquiries and rights requests	info@mhglobalgroup.com
Telephone	+44 207 377 9630
Postal address	MH Global Group Limited, 16 St. Clare Street, London, England, EC3N 1LQ

Please put 'Privacy request' in the subject line so that your message reaches the right people quickly. We will acknowledge a rights request and respond within one month; if a request is complex or you have made several, we may extend that by up to two further months and will tell you why within the first month.

We have not appointed a data protection officer, and are not required to appoint one under Article 37. We have not appointed a representative in the European Union under Article 27 EU GDPR. If we become required to appoint one, that representative's name and contact details will be published in the table above.

This notice forms part of our Terms of Service, which govern your use of MIE Auth. This notice deliberately uses plain lower-case words (organisation, member, account) for the things clause 2 of those Terms defines as 'Organisation', 'Member' and 'Account'; they mean the same thing.

2. Who this notice is for, and our role

In short: if you signed up for MIE Auth yourself, we are the controller and this notice governs. If your employer or another organisation gave you the account, that organisation is the controller of your account data and we act as its processor, but we remain the controller of the security records we keep to protect the service.

MIE Auth is a multi-tenant sign-in service. It holds accounts, verifies who you are, and issues sessions and access tokens to the applications that rely on it. Two relationships are possible, and which one applies to you decides who is answerable for your data. A third role applies to you whichever of them you are in.

We are the controller where you created your own account directly with MIE Auth. We decide what data the service needs to sign you in and keep the account secure, and this notice is our Article 13 notice to you.
We are a processor where an organisation account manages your access: for example where your employer created the organisation, invited you into it, and administers your membership, role and access policies. That organisation is the controller of your account and access data. It decides who is invited, what role you hold, whether two-factor authentication is mandatory and which networks may sign in; we process that data on its documented instructions. Your rights in that relationship are exercised against the organisation, and we will assist it in answering you. One exception, and you should know it: the export and erasure controls described in section 11 are available to every account holder, including members of an organisation. If you use them, we act on your instruction rather than the organisation's, the erasure is written to the organisation's audit trail where its administrators can see it, and where you were its only member the organisation is deleted with you (section 11.2). Otherwise the organisation's own privacy notice governs, not this one; this notice still tells you accurately what the service does.
We remain a controller, in both cases, for service integrity. The security audit trail, the sign-in throttling and lockout state, bot mitigation, and the list of email addresses we must stop mailing are things we do for our own purposes, to keep an identity service safe. No customer instructs us to do it and no customer can switch it off, so we are the controller of it. It is described in sections 4, 10 and 12.

Where we act as a processor, we do not use the personal data for our own purposes, do not sell it, and do not disclose it except to the sub-processors named in section 8 or where the law requires.

3. Where your personal data comes from

From you, when you create an account, sign in, enrol a second factor, register a passkey, change your email address, or contact support.
From your browser and network, automatically, on each request: your IP address (taken from Cloudflare's CF-Connecting-IP header) and your User-Agent string.
From a social identity provider, if you choose to sign in with one: the identity claims described in sections 5 and 6.
From an organisation, if one invited you: the email address it invited, the role it assigned you and its access policy for you.
From our fallback email provider, on a deployment that uses one, if a message to you hard-bounces or is reported as spam: the address and the reason, so that we stop mailing it.

4. What we hold, why, on what lawful basis, and for how long

In short: we hold what an identity service needs and no more: who you are, proof that it is you, which organisations you belong to, and a security record of what happened to your account. We never store your password, and the secrets behind two-factor authentication are encrypted before they are written down.

The table below is derived from the actual database schema. 'Until erasure' means the data is deleted when your account is erased, by you or by an operator acting on your request (section 11). Article references are to the UK GDPR; the EU GDPR has the same numbering where it applies to you.

Personal data	Why we hold it	Lawful basis	Retention
Name (`user.name`)	To address you in the interface and in email.	Contract, Art. 6(1)(b)	Until erasure
Email address and verification flag (`user.email`, `user.emailVerified`)	Your sign-in identifier; the address for verification, password reset and security alerts. It is unique across the service.	Contract, Art. 6(1)(b)	Until erasure
Profile picture URL (`user.image`)	Populated only from a social provider's `picture` claim when you sign in with one; used to show your avatar. We store the URL, not a copy of the image.	Contract, Art. 6(1)(b)	Until erasure
Password hash (`account.password`, credential accounts only)	To verify your password without holding it. Hashed with scrypt (a memory-hard key-derivation function) using a per-user 16-byte random salt and a 64-byte derived key, in a self-describing format that records its own cost parameters. The plaintext password is never stored, never logged and never included in any export.	Contract, Art. 6(1)(b)	Until erasure
Two-factor secret and backup codes (`twoFactor.secret`, `twoFactor.backupCodes`)	To verify time-based one-time codes and recovery codes. Both are encrypted at rest with the service's own key before they are written to the database; backup codes are never stored in plain text.	Contract, Art. 6(1)(b): a feature you chose to enrol in	Until you disable two-factor authentication, or erasure
Two-factor failure counter and lock (`twoFactor.failedVerificationCount`, `twoFactor.lockedUntil`)	To stop a second factor being brute-forced.	Legitimate interests, Art. 6(1)(f): securing accounts	Until the lock expires or is reset
Passkey credentials (`passkey.publicKey`, `credentialID`, `counter`, `deviceType`, `backedUp`, `transports`, `aaguid`, `name`)	To verify a WebAuthn sign-in. We hold only the public key and the authenticator's model identifier and backup state; the private key never leaves your device.	Contract, Art. 6(1)(b)	Until you delete the passkey, or erasure
Session records (`session.token`, `createdAt`, `expiresAt`, `activeOrganizationId`, `amr`, `impersonatedBy`)	To keep you signed in, to show you your active sessions, and to record how you authenticated (password, one-time code, passkey, social) so a relying application can tell.	Contract, Art. 6(1)(b)	Up to 7 days from your last use of the session. A session that stays in use is extended (at most once a day), so its record, including the IP address and user agent, lasts as long as you keep using it. Deleted immediately on sign-out, password change or reset; expired rows are removed by a sweep that runs every 15 minutes
IP address (`session.ipAddress`, `audit_log.ip`)	So that you can recognise your own sessions and spot one that is not yours, so new-device alerts are actionable, and so an attack on an account can be investigated.	Legitimate interests, Art. 6(1)(f), and our security duty under Art. 32	With the session: up to 7 days from your last use of it, and longer while you keep using it; in the audit trail, 90 days online, then archived (section 13)
User agent (`session.userAgent`, `audit_log.user_agent`)	Same purposes as the IP address; also used to decide whether a sign-in is from a device we have seen before.	Legitimate interests, Art. 6(1)(f), and Art. 32	As for IP address
Social account identifiers and tokens (`account.providerId`, `accountId`, `accessToken`, `refreshToken`, `idToken`, `accessTokenExpiresAt`, `refreshTokenExpiresAt`, `scope`)	`providerId` and `accountId` link your MIE Auth account to the account at the provider, so you land in the same account each time. The tokens are what the provider returned at sign-in.	Contract, Art. 6(1)(b)	Until you unlink the provider, or erasure
Organisation membership and role (`member.organizationId`, `member.role`; `tenant_assignment.node_id`, `role_id`, `created_by`)	To decide what you may see and do inside an organisation. `created_by` records which administrator granted the assignment; it is set to null on that person's erasure.	Contract, Art. 6(1)(b); where an organisation controls the account, we process this as its processor	Until you are removed from the organisation, or erasure
Invitations (`invitation.email`, `role`, `status`, `expiresAt`, `inviterId`)	To let an organisation invite you and to let you accept.	Legitimate interests of the inviting organisation, Art. 6(1)(f)	Until accepted or expired; expired rows are swept every 15 minutes. Erasure also deletes any pending invitation addressed to your email
API keys (`apikey.name`, `prefix`, `start`, stored key digest, `referenceId`, request counters, `lastRequest`, `expiresAt`)	To let you authenticate an integration without a password.	Contract, Art. 6(1)(b)	Until you delete the key or it expires; expired keys are swept every 15 minutes; erasure deletes all of your keys
Verification records (`verification.identifier`, `value`, `expiresAt`)	Short-lived tokens behind email verification, password reset, magic links and one-time codes. The identifier is stored as a SHA-256 hash, so a copy of the database cannot be replayed into an account takeover.	Contract, Art. 6(1)(b)	Minutes to hours; expired rows are swept every 15 minutes
Audit records (`audit_log`: organisation, actor type and id, action, target type and id, node path, IP, user agent, JSON metadata, timestamp)	The security record of the account: sign-ins, sign-outs, password resets, two-factor changes, backup-code regeneration, passkey registration and deletion, API-key creation and deletion, email-change requests, role grants, member removal, organisation creation, data exports and erasures, and pre-authentication denials (throttling, failed bot check, bad credentials, lockout). Two kinds of record contain your email address itself: a denial record, because the address under attack is the thing being recorded, and the receipt recording that a security notification was sent to you.	Legitimate interests, Art. 6(1)(f) (detecting and investigating account compromise), and Art. 32	90 days in the live database, then archived (section 13)
Access-token revocation cutoff (`user_revocation`)	A timestamp set when you sign out or change your password, so access tokens issued before it stop working immediately.	Legitimate interests, Art. 6(1)(f)	Until erasure (it is deleted with your account)
Email suppression records (`email_suppression.email`, `reason`, `created_at`)	Addresses that hard-bounced, were reported as spam or were invalid, so we stop mailing them. Sender reputation is shared across every organisation on the domain, and verification and password-reset mail is exactly the mail that must not be filtered.	Legitimate interests, Art. 6(1)(f): deliverability of security mail	Until removed by an operator on request, or erasure
Organisation security configuration (`org_security.updated_by`, `org_ip_allow.cidr`, `label`, `created_by`)	The organisation's own two-factor requirement and permitted sign-in networks, and a record of which administrator set them.	Legitimate interests of the organisation, Art. 6(1)(f)	Until changed; the administrator attribution is set to null on that person's erasure
Rate-limit and lockout state (in-memory and durable counters, keyed by IPv4 address or IPv6 /64 prefix, and by email address for sign-in lockout)	To stop credential stuffing, password guessing and email bombing.	Legitimate interests, Art. 6(1)(f), and Art. 32	Request counters expire with their window (60 seconds; 10 minutes for mail-sending); a lock lasts 15 minutes; failure counts decay after 1 hour
Request logs (request id, method, redacted path, status, duration, region, IP address, user id where known)	Operating the service and investigating faults and abuse.	Legitimate interests, Art. 6(1)(f)	Approximately 7 days, then deleted by the platform
Aggregate metrics (event type, a short detail such as a denial reason or route, region, outcome, duration)	Counting sign-in successes, failures and denials so that an attack or an outage raises an alarm. These records carry no name, email address or user id.	Legitimate interests, Art. 6(1)(f)	Retained in aggregate form only
Documents you authored (`document.created_by`)	Attribution of records inside an organisation, in the example 'documents' resource that ships with the service as a demonstration.	Legitimate interests of the organisation, Art. 6(1)(f)	The attribution is set to null on erasure; the organisation's record survives without your identifier

Where we rely on legitimate interests, we have balanced those interests against your rights. The interest is the security and availability of an identity service: without an audit trail, rate limiting, lockout and bot mitigation, a single stolen password becomes an undetected, persistent compromise of an account and of every application that trusts it. The data used is limited to what that requires, is not used for marketing or profiling, and is subject to the retention limits set out above. You may object at any time (section 11).

Do you have to give us this data? Your email address and at least one credential are a contractual requirement: they are what an account is, and we cannot create one or sign you in without them. Your name is not required. No statute obliges you to give us any of it. The only consequence of not providing it is that we cannot give you an account. Your IP address and user-agent string are collected automatically by the request itself and cannot be withheld while still using the service. Where an organisation invited you, it decided what to give us; ask that organisation.

We do not hold payment card details in this service, do not knowingly collect special category data (Article 9), and send no marketing email: every message MIE Auth sends is transactional or a security warning (section 7).

5. Google user data

In short: if you sign in with Google, we ask Google for three basic scopes, use what they return only to create and identify your account, and touch nothing else in your Google account.

This section describes precisely what MIE Auth does with data obtained through Google Sign-In. It applies only if you choose to sign in with Google.

5.1 The scopes we request

When you press 'Continue with Google', we send you to https://accounts.google.com/o/oauth2/v2/auth with these OAuth scopes:

openid: to receive a signed identity token asserting who you are;
email: your email address and whether Google has verified it;
profile: your basic public profile (display name and profile picture URL).

The request uses PKCE and returns to a fixed redirect URI on our own domain (https://auth.mhglobalgroup.com/api/auth/callback/google). We do not request sensitive or restricted scopes; if that ever changes we will update this notice before it takes effect. The request also sets include_granted_scopes, so Google may return scopes you have previously granted this application.

5.2 What we receive and store

We exchange the authorisation code at https://oauth2.googleapis.com/token and read the identity token Google returns. From it we take, and store:

sub: Google's stable identifier for your Google account, stored as the provider account identifier so that the same Google account always reaches the same MIE Auth account;
email and email_verified: used as your account email address and, where Google has verified it, to mark the address verified so you are not asked to verify it twice;
name: stored as your display name;
picture: stored as your profile picture URL.

We also store the tokens Google issued (the access token, the identity token, a refresh token where Google supplies one, their expiry times and the granted scope) against your account record, so that the link between the two accounts can be maintained.

5.3 What we do with it, and what we do not do

We use Google user data for one purpose: to create your MIE Auth account, to identify you when you return, and to sign you in. That is all.

We call no other Google API. We do not read, write, modify or delete anything in Gmail, Drive, Calendar, Contacts, Photos or any other Google service, and we hold no scope that would let us.
We do not sell Google user data, and we do not transfer it to anyone for advertising, data brokerage or credit purposes.
We do not use it for advertising of any kind, and we do not build advertising or behavioural profiles.
We do not use it to train any artificial intelligence or machine-learning model, our own or anyone else's.
We do not disclose it to third parties, except to the infrastructure sub-processors named in section 8 that host the service on our behalf, and except where the law compels us, and except in a merger, acquisition or sale of assets, for which we would ask your explicit prior consent.
Humans do not read it, except where you ask support for help, where it is strictly necessary to investigate a security incident or abuse, or where the law requires it.

MIE Auth's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

5.4 Withdrawing and deleting

You can disconnect MIE Auth from your Google account at any time at myaccount.google.com/connections. Doing so stops future sign-ins with Google; it does not by itself delete the data already stored here.

Erasing your MIE Auth account (section 11) deletes the account record holding your Google identifier and the stored Google tokens, along with the rest of your personal data, subject only to the audit-trail retention described in sections 4 and 13.

Which providers are available is a configuration choice. Google, GitHub, Microsoft Entra ID, Apple and other providers supported by the service can each be turned on or off by the operator; only providers with working credentials appear as buttons on the sign-in page, so what you can see is what is enabled.

For every provider, the pattern is the one described in section 5: we request basic identity scopes, receive an identifier, an email address, a display name and, where the provider supplies one, a picture URL, and we use them to create and identify your account. The provider's own privacy notice governs what it does at its end, including the fact that it learns you have signed in to MIE Auth. Signing in with a provider is entirely optional; an email address and password, a passkey or a magic link will do instead.

7. The emails we send you

In short: we send transactional and security email only. There is no marketing, so there is nothing to unsubscribe from. The security warnings cannot be switched off, because they are the only way we can reach you if someone else is in your account.

Email	When it is sent
Verify your email	On sign-up, and when you ask for a new verification link
Reset your password	When a password reset is requested for your address
Your sign-in link	When you request a magic link
Your one-time code	When a one-time code is requested for sign-in or two-factor authentication
You have been invited	When an organisation invites your address, naming the organisation and the person inviting
Confirm your new email address	To your current address, to authorise a change of address: the mailbox being moved away from is the one that has to approve the move
Your password was changed	After a password change or a completed reset
Two-factor authentication enabled / disabled	When your second factor is enrolled or removed
Your backup codes were regenerated	When a new set of recovery codes is generated
New sign-in to your account	The first time your account is signed in to from a device we have not seen before; it names the IP address, the device string and the time so that you can tell whether it was you
Your account was temporarily locked	Once per lock, after repeated failed sign-in attempts, and only where the address actually has an account
Your account was deleted	After an erasure completes

Security notifications carry no 'you can ignore this' footer and no one-click action link, deliberately: they exist for the case where someone else already controls your session, and they direct you to sign in rather than to click.

8. Third parties and sub-processors

In short: the service runs entirely on Cloudflare. Beyond that, a partial password hash goes to a breach-checking service, mail may go through a fallback transport where the operator has configured one, and social sign-in involves the provider you choose.

Recipient	What it does for us	What it sees
Cloudflare, Inc.	Hosts the whole service: Workers (application code), D1 (the database), KV (a non-personal directory of organisation slug to region), R2 (the audit archive and the nightly database backup), Turnstile (bot mitigation on sign-in and sign-up), Email Sending (outbound mail), Analytics Engine (aggregate counters), and the WAF, TLS termination and DDoS protection in front of it all.	All personal data described in section 4, as our sub-processor
Have I Been Pwned (pwnedpasswords.com)	Rejects passwords that appear in known breach corpora. This uses k-anonymity: we compute the SHA-1 hash of the candidate password locally and send only the first five hexadecimal characters of that hash to `api.pwnedpasswords.com/range/`, then compare the returned list of suffixes ourselves. Your password itself never leaves the service, and neither does the full hash of it. Only a five-character prefix is sent, from which nobody can work out which password it came from. Neither your name nor your email address is sent, and the request carries nothing that identifies you.	A five-character hash prefix, and nothing else
Resend	A fallback mail transport, used only on a deployment where the Cloudflare Email Sending binding is absent and an API key has been configured. Where it is in use, its delivery webhook tells us which addresses hard-bounced or complained, which is what feeds the suppression list.	The recipient address and the content of the message sent to you
Social identity providers (whichever the operator has enabled: Google, GitHub, Microsoft Entra ID, Apple or another supported provider)	Authenticates you if you choose that route.	That you signed in to MIE Auth, plus whatever the provider records about the authorisation

We do not use third-party analytics, advertising networks, tag managers, session recorders or social plug-ins. There is no advertising on this service.

We may also disclose personal data where we are legally obliged to (for example in response to a valid court order or a lawful request from a regulator or law enforcement body), and where necessary to establish, exercise or defend legal claims. If the business is reorganised, sold or merged, personal data may transfer as part of it; you would be told before it happened, and the protections in this notice would continue to apply. Google user data is excluded from this: where data obtained through Google Sign-In would transfer as part of such a transaction, we will obtain your explicit prior consent first, as the Google API Services User Data Policy requires.

9. Where your data is held, and international transfers

In short: the database, the audit archive and the database backups are pinned to the European Union (Western Europe). Cloudflare's network is global, so a request touches the edge location nearest you before it reaches us.

Data at rest is in the EU. The deployment is pinned to the EU region: the D1 database is a regional database in the European Union, and both the R2 bucket that holds the audit archive and the R2 bucket that holds the database backups are located in Western Europe.
The code runs next to the data. The Worker uses Cloudflare Smart Placement, which moves execution to the location of the database rather than leaving it at the edge location nearest to you.
The edge is global. Cloudflare terminates TLS and applies its WAF and DDoS protections at the point of presence closest to you, which may be outside the UK and EEA. Your IP address, the requested URL and your request headers are processed there in transit.
Some outbound calls leave the region: the Turnstile verification call to Cloudflare's challenge platform; the partial-hash lookup to Have I Been Pwned described in section 8; and, if you sign in with a social provider, the authorisation-code exchange and identity-token key fetch to that provider (for Google, oauth2.googleapis.com and www.googleapis.com). Outbound email leaves through the mail transport named in section 8.
Cloudflare is US-headquartered and operates global infrastructure, so personal data may be processed by it, or accessible to it, outside the UK and EEA. The same applies to Resend on any deployment that falls back to it.

Where personal data is transferred outside the UK or the EEA, we rely on the safeguards in Article 46 of the UK and EU GDPR. Those are the European Commission's Standard Contractual Clauses and the UK International Data Transfer Addendum, both incorporated in our processors' data-processing terms, backed by a transfer risk assessment. We add technical measures that limit what a recipient outside the region could actually obtain: encryption in transit, encryption of secret material at rest, and regional pinning of the database. Where a processor is certified under the EU-US Data Privacy Framework and its UK Extension, we may additionally rely on the adequacy decisions covering it. You can ask us for details of the safeguards relied on for a particular transfer at info@mhglobalgroup.com.

10. Cookies, local storage and similar technologies

In short: one cookie keeps you signed in, a few short-lived ones carry a sign-in flow from one step to the next, and the bot check runs on Cloudflare's challenge platform. All of them are strictly necessary, so none of them needs your consent. We set no analytics or advertising cookies at all.

Under the Privacy and Electronic Communications Regulations (PECR), consent is not required for storage that is strictly necessary to provide a service you have expressly requested. Everything MIE Auth stores on your device falls within that exemption, because signing in and staying signed in is the service, and defending the sign-in against automated attack is inseparable from it.

What is stored	Type	Purpose and properties	Lifetime	Consent
`__Secure-better-auth.session_token`	Cookie	Your session token: the value that keeps you signed in. Set with `HttpOnly` (unreadable by JavaScript), `Secure` (HTTPS only), `SameSite=None` and `Partitioned`, scoped to `.mhglobalgroup.com` so that the sign-in service and the applications on that domain share one session. Validated against the database on every request, so revoking a session takes effect immediately rather than when a cache expires.	Up to 7 days, refreshed as you keep using the service (at most once a day)	Strictly necessary; no consent required
Short-lived sign-in flow cookies	Cookies	Set only while a flow is in progress, and cleared when it completes: the OAuth `state` value and PKCE code verifier that protect a social sign-in redirect against tampering, and the interim cookie that carries you from the password step to the two-factor step.	Minutes	Strictly necessary; no consent required
Cloudflare Turnstile	Third-party script and storage on `challenges.cloudflare.com`	The bot check on the sign-in and sign-up forms. It analyses browser and interaction signals to decide whether the request is automated, and returns a token that we verify server-side, pinned to our own hostnames and to the specific form. Where Cloudflare's WAF issues a managed challenge in front of the service, it sets its own clearance cookie.	Per challenge / as set by Cloudflare	Strictly necessary (fraud and abuse prevention); no consent required
`miethemev1`	Browser local storage	Remembers whether you chose the light or dark theme, so the page does not flash the wrong one. It is never sent to us, and it holds nothing but the word `light` or `dark`.	Until you clear your browser storage	Strictly necessary for a display setting you expressly chose
`pendingInvitation`	Browser local storage	Holds the identifier of an organisation invitation you opened while signed out, so that it can be offered to you for acceptance or refusal after you sign in.	Removed as soon as the invitation is accepted or declined	Strictly necessary; no consent required

We set no advertising, marketing, profiling or third-party analytics cookies, so there is no consent banner and nothing for you to opt out of. You can delete cookies and local storage in your browser at any time; deleting the session cookie signs you out.

11. Your rights, and how this service implements them

In short: you can download the account data we hold on you, and erase your account, from inside the product: no email, no waiting. The export deliberately leaves out secret material, and the security audit trail is kept after erasure; 11.1 and 11.2 explain both. The one refusal we build in is described at 11.3.

Under the UK GDPR and, where it applies to you, the EU GDPR, you have the rights to be informed, of access, to rectification, to erasure, to restrict processing, to data portability, to object, and not to be subject to solely automated decisions with legal or similarly significant effects. You also have the right to withdraw consent where we rely on it; we do not rely on consent for any of the processing in section 4.

Exercising these rights is free. We will not charge you or refuse a request unless it is manifestly unfounded or excessive, and we will explain ourselves if we do.

11.1 Self-service, inside the product

Right	How	What happens
Access and portability	`GET /api/compliance/me/export` (the 'Export my data' control in your account)	Returns machine-readable JSON: your account record (id, name, email, verification flag, creation date); your sessions (id, creation date, IP address, user agent); your linked social accounts (provider and provider account id only); your organisation memberships and roles; your fine-grained role assignments; your passkeys (device label and enrolment date only); and the documents you authored. It deliberately contains no secret material: never your password hash, your two-factor secret or backup codes, your API-key digests, your OAuth tokens or your passkey public keys. A file you download over email should not be worth stealing. The export is itself recorded in the audit trail.
Erasure	`DELETE /api/compliance/me` (the 'Erase my account' control)	Irreversible, and therefore gated twice: you must type your own email address to confirm, and, if your account has a password, enter it. See 11.2 for exactly what is deleted.
Rectification	Your account settings	You can correct your name directly. Changing your email address sends a confirmation link to your current address, which is the only mailbox that can authorise moving the account away from itself.
Restriction, objection, and anything else	info@mhglobalgroup.com	We will respond within one month.

Organisation administrators holding the audit:read permission can additionally export their organisation's audit trail via GET /api/compliance/audit (JSON, or CSV with ?format=csv), which is how an organisation answers its own compliance obligations. Administrators see only their own organisation's records, and a manager scoped to part of an organisation sees only their own part of it.

11.2 What erasure actually deletes

Erasure runs as a single database transaction, so it either completes fully or changes nothing; there is no half-erased account. It deletes:

your user record, and with it, by cascade: every session, every linked social account and the OAuth tokens on it, your two-factor secret and backup codes, your passkeys, your organisation memberships, your fine-grained role assignments and your access-token revocation cutoff;
all of your API keys;
your outstanding password-reset and delete-account tokens; any other short-lived sign-in token issued to your address expires on its own and is removed by a sweep that runs every 15 minutes;
any pending invitation addressed to your email address, matched case-insensitively, because otherwise a stale invitation would keep a copy of your address indefinitely;
your email suppression record, if you had one;
where erasing you would leave an organisation with no members at all: that organisation, its structure, its documents and its routing entry, so that nothing is left orphaned.

Two things deliberately survive, and you should know it:

Records you authored inside an organisation that still exists are kept by that organisation, with your authorship set to null: the record remains, your identifier does not.
The security audit trail is retained under Article 17(3) and our Article 32 security duty: an identity service cannot delete the evidence of how an account was accessed the moment someone asks it to, and that evidence is what protects other users. Audit records identify you by user id rather than by name. Two kinds of record also contain your email address itself: sign-in denial records, which record the address that was targeted, and the receipts recording that a security notification was sent to you, including the receipt for the erasure itself. They leave the live database after 90 days and move to a restricted archive which has no automatic expiry today; section 13 explains that position and how to ask about your own records. If you want the audit position for your own account explained, write to info@mhglobalgroup.com.

An erased account can persist for a short period in an offline copy. Where a backup of the production database exists, erased data may persist in it until that backup expires, which is 35 days after the backup was taken (sections 12 and 13), so an erasure carried out today has worked through the backups within 35 days. We do not restore individual records from a backup, and we re-apply any outstanding erasure after a restore.

11.3 The one erasure we refuse, and why

If you are the sole owner of an organisation that still has other members, erasure is refused with a 409 response and the reason sole_owner_transfer_required. Nothing is deleted.

The reason is not administrative convenience. Erasing you would cascade away the last account able to manage that organisation, stranding every remaining member in an organisation that nobody can administer, invite to, or delete. That is a harm to other people that cannot be undone without direct intervention in the production database. Transfer ownership to another member, or remove the remaining members, and the erasure proceeds immediately. If you cannot resolve it yourself, contact info@mhglobalgroup.com and we will help.

11.4 Operator-assisted requests

If you cannot sign in, our support team can act for you once your identity is established:

GET /api/support/user/:userId/export: the same export as 11.1, returning exactly the same set of data, because both doors call the same code;
DELETE /api/support/user/:userId: the same erasure as 11.2, with the same sole-owner refusal;
POST /api/support/unlock: clears a sign-in lockout;
POST /api/support/2fa-reset: removes a two-factor enrolment you have lost access to;
DELETE /api/support/suppression/:email: removes your address from the suppression list so that we can mail you again.

These routes are restricted to authorised operators, require multi-factor authentication, and every use is written to the audit trail with the operator's identity. Write to info@mhglobalgroup.com to ask for any of them.

12. How we protect your data

In short: everything is encrypted in transit, passwords are hashed and checked against breach corpora, second factors and bot mitigation guard the sign-in, and every meaningful action leaves an audit record.

These are measures the service actually implements, not aspirations.

Encryption in transit. The service is served only over HTTPS, with TLS terminated by Cloudflare. Session cookies are marked Secure and HttpOnly, and pages are served with a Content Security Policy.
Password storage. Passwords are hashed with scrypt (per-user random salt, 64-byte derived key, self-describing cost parameters) and compared in constant time. Plaintext is never stored or logged.
Password policy. Minimum 12 characters, maximum 256.
Breached-password rejection. Candidate passwords are checked against the Have I Been Pwned corpus by k-anonymity, sending only a five-character hash prefix (section 8).
Email verification is required before an email-and-password account can sign in.
Two-factor authentication: time-based one-time codes with encrypted secrets and encrypted backup codes, one-time codes by email as a fallback, and phishing-resistant passkeys pinned to our own origins. Multi-factor authentication is mandatory for privileged roles, and an organisation can require it of all of its members.
Sign-in lockout. Five failed attempts against an address lock it for 15 minutes; the failure count decays after an hour. The owner is emailed once, on the lock itself.
Rate limiting. Every authentication mutation is throttled per client network (30 requests per minute, with IPv6 grouped by /64 so it cannot be evaded by rotating addresses). Mail-sending endpoints are additionally throttled per recipient (at most 3 messages to a given address in 10 minutes), so our flows cannot be used to flood an inbox.
Bot mitigation. Cloudflare Turnstile guards sign-in and sign-up. Verification happens server-side and is pinned both to our own hostnames and to the specific form, so a token solved elsewhere cannot be replayed here. An unverifiable token fails closed.
Session and token revocation. Sessions are checked against the database on every request, so revocation is immediate. Access tokens last 15 minutes, are bound to the session that minted them, and are rejected once that session is revoked or the account's revocation cutoff moves. Signing tokens are ES256 and the signing key rotates every 90 days. Changing your password, resetting it, or enrolling a second factor destroys every other session.
Secret material at rest. Two-factor secrets, backup codes, token-signing private keys and stored OAuth client secrets are encrypted before being written to the database. Verification and reset tokens are stored as hashes.
Least privilege. Access inside an organisation is resolved from explicit role assignments scoped to part of its structure; an organisation can also restrict sign-in to named networks. Administrative impersonation is recorded against the administrator, not the user.
Audit logging. Section 4 lists what is recorded. Audit writes can never break an authentication flow, and a failed write is recorded as an error in our operational logs.
Backups. A nightly export of the production database to encrypted object storage in Western Europe is configured, and every export expires automatically 35 days after it is taken. Access to the backup bucket is equivalent to access to the production database and is restricted accordingly.
Monitoring. Authentication outcomes and denials are counted continuously as a time series, so that a credential-stuffing campaign or a failure of the mail path is visible to us.

The audit trail is designed to support SOC 2-style evidence requirements. To be clear, that is a description of the capability: it is not a claim that we hold a SOC 2, ISO 27001 or any other certification, and nothing in this notice should be read as one.

No service can promise perfect security, and we do not.

13. Retention summary

Data	Retention
Account record, credentials, second factors, passkeys, memberships and role assignments	Until you erase your account, or an operator erases it at your request
Sessions (including IP address and user agent)	Up to 7 days from your last use of the session; a session that stays in use is extended (at most once a day), so the record lasts as long as you keep using it. Expired rows deleted by a sweep every 15 minutes; deleted immediately on sign-out, password change or reset
Access tokens	15 minutes, and invalid sooner if the session is revoked
Verification, password-reset and magic-link tokens	Minutes to hours; expired rows swept every 15 minutes
Invitations	Until accepted or expired; expired rows swept every 15 minutes
API keys	Until deleted or expired; expired keys swept every 15 minutes
Audit records	90 days in the live database, then moved to an archive in Western Europe as part of the security record. The archive is not on a fixed automatic expiry today; we keep it only for as long as it is needed as evidence of security events and to meet our customers' own audit obligations, and we review that period. Ask us at info@mhglobalgroup.com for the position on your own records
Email suppression records	Until removed on request, or erased with the account
Rate-limit and lockout state	Window-lifetime only: 60 seconds (10 minutes for mail sending); locks 15 minutes; failure counts decay after 1 hour
Request logs	Approximately 7 days
Aggregate metrics	Retained in aggregate; they contain no identifiers
Database backups	35 days from the date of the backup, then deleted automatically

14. Automated decision-making and profiling

We do not make decisions about you by solely automated means that produce legal effects or similarly significantly affect you, within the meaning of Article 22 UK GDPR and EU GDPR. We do not profile you, score you, or use your data to predict your behaviour, and we do not use your personal data to train any AI or machine-learning model.

The service does apply automated security controls: per-network rate limiting, sign-in lockout after five failed attempts, and the Turnstile bot check. These decide whether to allow a single request through; they are time-limited, self-clearing and reversible, and they do not have legal or similarly significant effects. If one of them blocks you unfairly, a human can review it and clear it immediately (section 11.4), and you can ask for that at info@mhglobalgroup.com.

15. Children

MIE Auth is a business authentication service. It is not designed for, directed at or marketed to children, and we do not knowingly create accounts for anyone under 16. If you believe a child has an account with us, write to info@mhglobalgroup.com and we will investigate and erase it.

16. Personal data breaches

We maintain procedures to detect, investigate and report personal data breaches. Where a breach is likely to result in a risk to your rights and freedoms, we will report it to the Information Commissioner's Office without undue delay and, where feasible, within 72 hours of becoming aware of it. Where it is likely to result in a high risk to you, we will tell you directly and without undue delay, and we will explain what happened, what data was involved and what you should do. Where we act as a processor for an organisation, we will notify that organisation without undue delay so that it can meet its own obligations.

17. Changes to this notice

We may update this notice as the service changes or the law does. The 'Last updated' date at the top always reflects the current version. If a change materially affects your rights or how we use your personal data, we will tell you before it takes effect: by email to the address on your account, or by a prominent notice when you next sign in. Continuing to use MIE Auth after a change takes effect means the updated notice applies to you.

18. Complaints

If you are unhappy with how we have handled your personal data, tell us first at info@mhglobalgroup.com. We would rather put it right than have you take it elsewhere, and we will respond within one month.

You also have the right to complain to a supervisory authority, without going to us first. In the United Kingdom that is the Information Commissioner's Office:

Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF
Telephone: 0303 123 1113
https://ico.org.uk/make-a-complaint/

If you are in the European Economic Area, you may instead complain to the supervisory authority of the EU or EEA member state where you live, where you work, or where you believe the infringement took place.

Back to sign in