Buy an evidenced control boundary
An authentication platform may advertise roles, audit logs and tenant isolation, but those labels do not establish how the controls behave in the buyer's intended workflows. A procurement assessment should ask who can read, export, change and administer which customer's data, how lifecycle changes affect access and what evidence records those actions. A successful demonstration by an administrator is not a negative test of unauthorized access.
Azure's multitenant identity guidance distinguishes authentication, authorization and commercial entitlements. Use those distinctions to structure buyer questions rather than assuming a login role covers every resource and action. This article is a requirements framework, not a claim that EmailAuth or another named platform implements the proposed controls. No tenant was accessed, permission changed or product purchased.
Define the buyer's access matrix first
List the expected user and service roles, tenant relationships and resources before reviewing a supplier's role names. Include domain configuration, authentication reports, raw data, exports, integrations, user administration and commercial settings where relevant. For each combination, state whether read, create, modify, delete or export should be allowed. The buyer's intended boundary is the reference against which product behavior can be assessed.
Do not assume that “read only” excludes export or that “tenant administrator” is confined to one tenant without evidence. Shared-service teams may legitimately need several customers, while individual customer users should see only their approved scope. Record those exceptions explicitly. A broad role accepted for a trial should not silently become the production access design. Require the supplier to map actual roles to the buyer's matrix and identify unsupported distinctions.
Verify tenant binding beyond the interface
A tenant selector or a hidden navigation item is not sufficient proof of isolation. The authenticated identity must be authorized for the requested resource at the server-side boundary. Requirements should cover direct reads, searches, exports, writes and background jobs, including references to resources owned by another tenant. Use synthetic fixtures with visibly different data so an accidental cross-tenant result is detectable.
Azure's guidance warns that federation misconfiguration can grant access to unintended tenants. The review should therefore include how identities are associated with tenants, who can change that association and how a user belonging to multiple tenants selects scope. Do not infer ownership from an email suffix alone or assume that a customer-provided tenant identifier authorizes its use. The actual supplier must explain and demonstrate its supported model.
Ask what the audit log actually records
Microsoft Entra's audit-log documentation describes activity records for changes in that identity environment. It is a useful example of an official audit-log model, not evidence that another platform records the same events. A buyer should request the exact product event catalogue, field definitions, access controls, retention behavior and export options relevant to their own requirements.
Ask whether records identify the actor, target, action, time, result and tenant context sufficiently to investigate a change. Distinguish user activity from service-identity activity and successful actions from denied attempts. Do not assume every failed authorization attempt is logged merely because administrative changes appear. Likewise, a log showing that a request was submitted may not show whether the resulting change completed. Require actual examples with sensitive data redacted and limitations stated.
Review log access and integrity as controls
An audit log can itself contain sensitive customer and identity information. Define who may view it, search across tenants, export it and configure its retention. An administrator who can change a setting and erase the only evidence presents a different accountability model from one with independently retained records. Ask the supplier how those controls work, but do not claim immutability or tamper resistance without current evidence.
Retention should be specified by the product's actual supported terms and the buyer's obligations, not an invented universal period. Clarify which events are available in the interface, API and exported archive and whether those views have the same coverage. Review time-zone handling and identifiers so records can be correlated without relying on names that may change. No audit records were retrieved for this manuscript.
Test lifecycle changes and service access
A role reduction, user disablement and credential revocation are separate events. RFC 7643 describes the SCIM active attribute while leaving its definitive meaning to the service provider. That illustrates why a buyer cannot assume a provisioning update revokes all existing sessions or integration credentials. Require a current explanation of the product's session and noninteractive-access behavior.
The acceptance plan should include a user whose role is reduced while a session exists, a disabled identity, an integration with limited scope and an authorized administrator. Verify the intended access result in each case, including exports and direct resource operations. These are proposed checks for an authorized isolated environment, not permission to test a supplier's production service or another customer's tenant. No such action was performed here.
A buyer acceptance worksheet
Create a worksheet with requirement, business reason, supplier claim, supported configuration, fixture identity, tenant, action, expected result, actual evidence and unresolved limitation. Keep evidence of allowed actions separate from evidence of denied actions. Include the product version, test date and environment so the result remains interpretable after a release. If a feature is planned rather than implemented, record that status without treating it as current coverage.
For audit logs, add the expected event and the observed record reference for each action where logging is required. A test that correctly denies access but produces no expected audit evidence has a different outcome from one that satisfies both criteria. Record who accepts any limitation and whether a compensating control is approved. Do not turn a procurement checklist score into a guarantee of future security.
Fictional diagnosis: a viewer who can export
A fictional buyer sees a vendor demonstration in which a viewer cannot edit domain settings. The buyer initially marks the read-only role as satisfactory. The intended matrix, however, also prohibits bulk exports of raw customer data. The demonstration never tested exports, direct resource requests or access to another tenant's report. The observed restriction covers only one action.
The proposed response is to ask for authorized fixture-based evidence across the missing operations and review the resulting audit records. If the product cannot separate viewing from export, the buyer must decide whether that limitation is acceptable rather than rename the role and assume the risk disappeared. This is a fictional procurement exercise, not a finding about EmailAuth or any named vendor.
Keep the purchasing conclusion bounded
A useful conclusion identifies requirements met by evidence, requirements unmet, limitations accepted by an owner and tests still open. It distinguishes configuration choices from inherent product behavior and does not promise perfect isolation from a finite test set. The decision can be informed without claiming that every future version or configuration is covered.
The catalogue requires an access matrix and negative tests for cross-tenant reads, exports, writes and lifecycle changes. Those original tests remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies the assessment method, not a purchase recommendation based on executed evidence, and no commercial commitment or access grant has been made.