Access control
Use least privilege. Separate company configuration, helpdesk work, audit review, security response, privacy handling, and production approval when your policy requires it.
Company Administrator Guide
Configure with evidence. Launch with confidence.
This guide is for authorized company administrators, helpdesk teams, security operators, and project owners. It explains the customer responsibilities that support a safe MYID deployment without exposing platform secrets or private infrastructure.
Last reviewed July 18, 2026
Production approval belongs to the customer
Test MYID with the intended providers, permissions, policies, data, devices, support process, security controls, and rollback plan before production use. A populated configuration is not proof that an integration works.
Test MYID with the intended providers, permissions, policies, data, devices, support process, security controls, and rollback plan before production use. A populated configuration is not proof that an integration works.
Responsibilities
Keep authority, configuration, and evidence clear.
Capability control
Enable only the mobile functions backed by a tested provider, approved permissions, a support owner, and a documented recovery path.
Secret handling
Keep service passwords, API tokens, private keys, OTP values, setup secrets, and authorization data in approved secret storage. Never place them in tickets, guides, screenshots, or source control.
Evidence review
Review connection tests, release results, audit events, performance measurements, known limits, and rollback readiness before approving a change.
Company onboarding
Complete readiness in a controlled order.
1. DefineConfirm the company identity, approved branding, support path, data scope, owners, and intended user functions.
2. ConnectConfigure the identity, directory, messaging, security, device, training, and notification providers in scope.
3. TestRun live connection and functional tests using approved test accounts and representative conditions.
4. ApproveReview security, privacy, audit, performance, support, release, and rollback evidence before distribution.
Required company information
Confirm a stable company identifier, display name, logo, support contact, identity source, user naming rules, approved mobile modules, privacy roles, retention instructions, and escalation owners.
Setup material
Issue a setup QR code or company identifier only after live readiness tests pass. Reissue setup material when its secret or onboarding contract changes. Users should always confirm the company shown in the app.
Pilot scope
Begin with authorized test users who can validate common success paths, policy denials, provider outages, slow responses, already completed actions, account lockout, device replacement, and helpdesk escalation.
Integration readiness
Test every provider as a separate dependency.
Identity provider
Validate issuer information, client identity, required permissions, callback configuration, token claims, user mapping, timeout policy, and a complete test user sign in.
Directory
Validate protected connectivity, certificate trust, search scope, account mapping, read and write permissions, password behavior, profile updates, and both locked and already unlocked test accounts.
Email and SMS
Validate recipient lookup, destination masking, sender identity, OTP expiration, attempt limits, delivery results, failure handling, and safe audit redaction.
Security information
Validate authorization, user mapping, incident scope, risk evidence, activity access, lockout source parsing, freshness, and the behavior shown when the provider is unavailable.
Device and training
Confirm that device and training identifiers map to the signed in user. Missing or unconfigured data should not become a false user failure.
Notifications
Test device registration, delivery, protected routing after authentication, revoked devices, company changes, duplicate delivery, and unavailable destination content.
Result integrity
Separate the primary action from optional evidence.
Truthful user state
- Show live, cached, degraded, pending, unavailable, denied, and failed results accurately.
- Do not refresh a timestamp when no successful live checkpoint occurred.
- Do not turn missing evidence into a healthy result.
- Do not treat an optional security provider failure as proof that a directory action failed.
- Confirm final provider state after a delayed response when the operation permits it.
Mobile capability state
- Confirm every enabled action remains available after navigation and app resume.
- Confirm an intentionally disabled function remains unavailable.
- Confirm company changes clear the visible session promptly.
- Confirm cached information is isolated by company and user.
- Confirm photo refresh stays outside the critical dashboard synchronization.
Audit and tenant access
Use W7 records with explicit capture boundaries.
WhoThe authorized actor or system context associated with the action.
WhatThe request, operation, resource, and available sanitized evidence.
WhenStart, completion, duration, and event time in a consistent time standard.
WhereThe service, tenant, route, client context, and provider involved.
WhyThe stated reason or workflow purpose when it is available.
HowThe channel, authentication context, provider method, and protection used.
OutcomeThe resulting state, response status, error category, and completion quality.
Capture quality
Audit records can include correlation, duration, sanitized request and response evidence, byte length, hash, truncation status, and capture mode when the transport makes them available. Binary, oversized, redacted, partial, or unavailable content must be identified honestly.
Never describe a partial or summarized value as an exact wire copy.
Customer access
Tenant access must be derived from an approved signed identity and must never rely on a company identifier supplied by the caller. Direct access depends on issued credentials, expiration, revocation, and tested tenant authorization.
Until customer access is enabled for a deployment, request an approved tenant scoped export through the MYID platform team.
Performance
Measure the experience without collecting user content.
Approved mobile telemetry can summarize timing, outcome, normalized operation, platform, app version, build, and frame quality. It should not require passwords, OTP values, request bodies, profile contents, push tokens, or service credentials.
Access path
Review company lookup, sign in, device verification, OTP delivery, and failure rate separately so one slow dependency does not hide inside a combined number.
Synchronization
Review total duration, joined refreshes, live checkpoints, degraded sections, provider delay, repeated downloads, accepted samples, and dropped samples.
Percentiles
Use typical and slower experience percentiles together. Averages alone can hide a serious regression for a smaller group of users.
Interface quality
Review frame time and jank by platform, version, and build. Compare the release with its approved baseline and representative devices.
History
Confirm that an approved monitoring system is collecting durable measurements before relying on trends across a server restart.
Data minimization
Keep user entered values, credentials, full request content, and stable device secrets out of performance samples.
Launch readiness
Complete this checklist before broad distribution.
| Area | Required evidence |
|---|---|
| Company setup | Correct branding, support path, company lookup, current setup material, and intended capability policy. |
| Authentication | Successful sign in, required verification, expiry, cancellation, retry limits, trusted device behavior, and biometric resume. |
| Identity actions | Profile, password, MFA, directory status, unlock, recovery, activity, and device tests for every enabled function. |
| Security experience | User scoped incidents, pending evidence, risk state, notification routing, response choices, and automatic protection policy. |
| Synchronization | Accurate freshness, local startup, manual refresh, background work, degraded providers, photo cache, and company isolation. |
| Audit | W7 fields, correlation, sanitized capture, completeness status, tenant isolation, retention, export, and support access. |
| Performance | Representative baseline, slower experience percentile, failure rate, frame quality, provider breakdown, monitoring ingestion, and alert owners. |
| Operations | Helpdesk guide, escalation owners, privacy process, security contact, release record, artifact integrity, rollback rehearsal, and known limits. |
Record every decision
Keep the tested app build, server release, company configuration version, test account purpose, time, result, correlation identifiers, performance comparison, approver, and rollback threshold. Do not record passwords, OTP values, tokens, keys, or private provider credentials.
Keep the tested app build, server release, company configuration version, test account purpose, time, result, correlation identifiers, performance comparison, approver, and rollback threshold. Do not record passwords, OTP values, tokens, keys, or private provider credentials.
Support and change control
Give support teams useful evidence and a safe escalation path.
Include in an escalation
- Company identifier and display name
- Affected user only when authorized
- App version, build, and platform
- Date, time, and time zone
- Operation and exact visible message
- Correlation and sanitized event identifiers
- Affected provider and result category
- Whether data was live, cached, degraded, pending, or unavailable
Release record
- Source backup and restore check
- Linked code and documentation changes
- Automated and manual test results
- Artifact integrity value and deployment record
- Performance comparison
- Health and core flow checks
- Known issues and accepted risk
- Rollback artifact and decision threshold