Separation and audit
The two questions a client asks before they let anyone manage their phones: can your other clients see us, and can you show me what your engineers did.
One client cannot find another
An account can be restricted to named clients. Everything the console shows is filtered by that list, including the device search, the audit log and the billing figures.
The part that matters is what happens at the edge. Asking for a device that belongs to a client you are not allowed to see returns exactly what asking for a device that does not exist returns. There is no "not authorised" to tell you that you found something. A restricted account cannot enumerate what it is missing.
Nobody wipes a phone on their own
Wiping a handset is the one action in the console that cannot be undone and cannot be explained away afterwards. It needs a written reason, and the reason is checked on the server rather than by the form, so it cannot be skipped by anyone who knows how to post a request directly.
Two-person approval is a setting. With it on, a wipe becomes a request that a second engineer sees, reads the reason, and approves or does not. Requests lapse after two hours, because an approval sitting open for a day is an approval against a situation that has moved on.
The audit log is meant to be handed over
Every action that changes something is recorded with the engineer who did it, the client it affected, what it was done to, why, and the address the request came from. The engineer's email address is written into the row rather than referenced, so the record still names them after the account is gone.
Entries are grouped, because the log answers two different questions for two different audiences. What happened to this client's devices is operational. Which accounts exist and when they signed in is reconnaissance for anybody who has taken over a lesser account, so it is kept to administrators.
Administrators can export the whole thing as CSV. The export is itself recorded, because that is the moment audit data leaves the system.
Why the log can be shown unaltered
Each entry covers the hash of the one before it. Editing a row, or deleting one, breaks every hash after it, and the break points at where it happened.
Anyone with write access to a database can change a row. The chain does not stop that. What it does is make the change show, which is the only property that makes a log worth anything in a dispute.
The chain is verified when an administrator opens the audit page, and again on a schedule whether or not anybody is looking. A break raises an alert on every administrator's screen, emails them, and is written to the server log so it leaves the machine before anyone can dismiss the banner. Tamper-evidence that nobody checks is just a log.
Credentials at rest
The database holds things that would be worth stealing: each client's Apple push certificate, device unlock tokens, and the console's own certificate authority. Those columns are encrypted with a key kept outside the database, so a copy of the file is not a copy of the credentials.
Backups are encrypted to a key the server does not hold the private half of, and go to storage the server can write to but cannot read back, overwrite or delete. A machine that has been taken cannot read last week's backup and cannot destroy it.
What we are not claiming
There is no external audit behind any of this, and no certification. It is a description of how the software works, which you are welcome to check: the console is yours, on your server, and the behaviour above is covered by tests you can run.
Questions worth a real answer
If a client's procurement has sent you a list, send it over. A specific answer is more use to both of us than a page of assurances.