Security Disclosure

1. Architecture

MYID includes a Flutter mobile application, a Java service and API layer, a protected administration console, a PostgreSQL data layer for configured production use, and adapters for identity, directory, security, training, messaging, and mobile notification providers.

The mobile client is not intended to contain provider client secrets, service account keys, directory bind credentials, QRadar tokens, messaging secrets, or cloud administration credentials. Provider calls that require such secrets are performed by the server or approved infrastructure.

2. Tenant controls

Company configuration identifies the tenant, enabled modules, active provider, branding, support route, and integration settings. The mobile app should show only functions the company enables and the server can support.

Tenant scoped audit and performance contracts derive the company from a signed token rather than accepting a caller selected company value. Direct customer credential issuance, expiration, and revocation must be operationally provisioned before a customer receives direct API access. Until then, approved tenant exports are provided through the platform team.

3. Identity and session security

Server authentication and authorization use signed session or access tokens, tenant context, role or scope checks, and route protection. Refresh credentials and access credentials have different purposes and should not be accepted interchangeably. Revoked sessions should be rejected by protected APIs.

Administrator access is designed for enterprise identity protection and role control. A platform administrator account must not be supplied to a customer merely to provide tenant data.

4. Mobile security

Protected local storage is used for eligible company and session state. Biometric return uses the operating system authentication service and does not send a face or fingerprint template to MYID. Sensitive actions can require a new biometric or OTP step.

The app validates company bootstrap data, protects signed in routes, scopes caches by company and user, and can route notifications to protected screens after authentication. Profile images can use a local cache and a separate background refresh path.

5. Data and secrets

Production deployments should use encrypted network transport, protected secret references, least privilege provider identities, restricted database roles, encrypted backups, and separated environments. The exact implementation must be verified for each customer environment.

Passwords, proposed passwords, OTP values, recovery codes, authorization values, tokens, cookies, API keys, client secrets, private keys, push tokens, and similar authentication material must not be stored in ordinary logs or public support messages.

6. W7 audit evidence

MYID structures API and business audit evidence around Who, What, When, Where, Why, How, and Outcome. Records can include tenant, actor, method, route, status, duration, correlation, capture mode, safely captured values, length, and integrity data.

A record must say whether a request or response body was complete, partial, summarized, or unavailable. Exact length and integrity data are recorded only when all bytes were observed. Binary, large, unknown length, or connector specific payloads can have limited capture.

Shared web client integrations can capture outbound response evidence. A generic client filter cannot always read the final serialized outbound request body without changing the request. Non web client integrations such as LDAP, SMTP, Firebase, and process based adapters require dedicated feature evidence. The platform must not claim universal exact wire capture until each adapter provides it.

Audit events are stored in the configured platform data layer. Immutable storage, cryptographic record chaining, customer credential lifecycle, scheduled archival, and automated deletion are deployment controls that must be separately provisioned where required.

7. Performance telemetry

Mobile telemetry can collect bounded samples for API duration, status, normalized operation, frame build time, frame raster time, and jank. It is designed to exclude credentials, request bodies, device identifiers, and user entered values.

Protected administration endpoints can provide current run tenant summaries with counts, failure rate, average, percentiles, maximum, frame timing, and normalized operation breakdowns. Durable history across server restarts requires an authenticated Prometheus collection identity and a configured monitoring store.

Collection limits, normalized tags, bounded tenant buffers, and a kill switch reduce the risk that telemetry affects the user operation it measures.

8. Connected providers

Every provider has its own permissions, availability, security, data, timeout, and consistency behavior. MYID capability flags do not replace a live readiness test. A provider authorization failure must be attributed to that provider and must not be presented as failure of an unrelated identity action.

MYID should not expose company wide security incidents to an individual when ownership cannot be established. A pending or missing provider result must not be converted into a final healthy result.

9. Development and release

The release process can include source review, unit and integration tests, static analysis, platform builds, dependency review, secret scanning, representative smoke tests, performance tests, backup, rollback material, and documented production gates.

A passing build does not prove production readiness. Provider permissions, real device behavior, notification delivery, customer data mapping, observability, legal approval, and rollback must also be validated. Unresolved findings should keep a release out of customer production.

10. Operations and resilience

Recovery time, recovery point, availability, support time, monitoring coverage, retention, and notification commitments apply only when documented for the specific deployment or signed agreement. This public page does not promise a universal uptime or recovery objective.

Customers should maintain an independent helpdesk and identity recovery path. A mobile self service product must not become the only way to recover from the failure of that same product or a connected provider.

11. Customer responsibilities

Customers must test every enabled action in a representative environment, provide lawful instructions and notices, control administrator and provider permissions, maintain secret and network security, verify audit and retention needs, monitor results, train support teams, preserve a rollback path, and obtain their own legal and compliance approval.

Customers must disable an action that is not fully configured or behaves unexpectedly. Security and identity actions should be verified against the authoritative provider when a result is delayed or uncertain.

12. Security incidents

SPS investigates reported security concerns, takes proportionate containment and remediation action, preserves relevant evidence, and communicates with affected customers as required by the signed agreement and applicable law. A public page does not replace a customer incident response plan.

Report a suspected MYID vulnerability or unauthorized access to security@ext.myidselfverify.com. Do not include credentials or access data you do not own.

13. Compliance and assurance

MYID supports security programs informed by NIST SP 800 53 and Virginia SEC530, with identity, authentication, audit, privacy, and response capabilities that help customers address applicable requirements under HIPAA, PCI DSS, GLBA, FERPA, CJIS, and privacy laws.

Review the Compliance page for framework coverage, control evidence, and official sources.

14. Responsible disclosure

Act in good faith, respect privacy, avoid disruption, use only accounts and data you are authorized to use, and do not publicly disclose a suspected issue before SPS has a reasonable opportunity to investigate. Written authorization is required before testing production security.

Send the affected service, safe reproduction steps, observed result, potential impact, and contact information to security@ext.myidselfverify.com. SPS does not promise a reward or safe harbor beyond what is stated in a separate written authorization.