WEIMI / OLD FACTOR · NEW DEVICE · CHANGE NOTICE
Specify reauthentication, factor-change notifications and the boundary between replacement and lost-factor recovery.
A working session is not the whole change-authorisation record.
A notification is a separate observable outcome.
A hypothetical vending supervisor receives a new phone while the old authenticator still works. The supervisor is already signed into the fleet dashboard and finds a settings page for changing the login factor. Purchasing needs to know which evidence authorises that change, because a routine device migration alters a future route into the account.
OWASP’s Multifactor Authentication Cheat Sheet treats factor replacement as a high-risk action. Its guidance recommends reauthentication with an existing enrolled factor, says not to rely solely on an active session and recommends notifying the user through an out-of-band channel whenever a factor changes.
This guide focuses on replacing an enrolled factor. It does not choose the initial MFA method, assess shopper checkout or report a security test on WEIMI accounts. It also distinguishes planned replacement with the old factor available from recovery after a factor has been lost.
Ask how the quoted operator service authorises a replacement before the new factor becomes trusted. The provider should explain the existing-factor reauthentication step, the applicable risk checks and the change-notification route. A successful dashboard login earlier in the day is not the complete purchasing record for this action.
OWASP recommends treating replacement as high risk and applying risk-based checks, with new device or unusual location as examples. It also suggests considering delays or step-up verification for high-value accounts. These recommendations do not establish a universal waiting period or prove the implementation of any vending service.
Define planned migration and lost-factor recovery separately. When the old factor is unavailable, require the provider’s approved recovery explanation rather than assume the normal replacement step can simply be skipped. No recovery bypass is demonstrated or recommended here.
| Item | Evidence question | Boundary |
|---|---|---|
| Active operator session | What additional proof authorises change? | Sign-in status alone is insufficient in OWASP guidance |
| Existing enrolled factor | Is reauthentication required and observed? | Normal replacement with old factor available |
| Risk policy | Which account and request checks apply? | Examples are not verified service features |
| Out-of-band notice | Who receives a change message and where? | Notification is separate from authorisation |
| Lost old factor | Which approved recovery route applies? | Do not infer a normal-path bypass |
Separate the authorising evidence from the message that reports a completed change. A provider may show both in one demonstration, but they answer different acceptance questions.
Use this brief when connected vending equipment includes an authenticated management service and human operators maintain enrolled MFA factors. It is useful for fleet teams replacing staff phones, distributors coordinating administrator access and employers whose service accounts are administered through an operator portal.
First confirm the actual management arrangement. The supplier may provide an application, rely on an external identity provider or offer a service package with responsibilities shared between parties. Ask who controls enrolment and replacement in the proposed configuration.
A retail touchscreen, employee dispensing badge or AI camera does not establish this human-account workflow. This requirement concerns the administrator’s login factor and future account access. It should be included only where that service forms part of the real quotation and operation.
WEIMI public hardware evidence was reviewed on 10 October 2026. OWASP’s Multifactor Authentication Cheat Sheet was read on 11 October 2026. The evaluation combines a public hardware shortlist with a proposed factor-change evidence schedule. No real operator authenticator was changed, and no candidate account was independently tested.
Ask the provider to identify the normal replacement route and the responsible service. Use a designated test identity in a provider-approved environment, with the old test factor available for the planned migration case. Agree the demonstration scope before any action.
Observe the factor-change request, the additional authentication step and the resulting notification. Ask the provider to explain which risk policy applies to the designated account and what happens when required proof is missing. Record incomplete or unshown cases rather than infer a pass.
For a separate lost-factor scenario, request the documented recovery route and its owner. The provider’s explanation should state the boundary between migration and recovery. Retain redacted results without authentication codes, enrolment secrets or live customer data.
Existing-factor proof: OWASP recommends reauthentication with an existing enrolled factor before a change. Ask which step performs that proof in the quoted service; a generic confirmation dialog does not explain it.
Active-session limits: the source warns that a session may be hijacked. Require the provider to describe the evidence beyond being signed in, without assuming every session is compromised or claiming a vulnerability exists.
Risk checks: ask how the provider’s actual policy treats the change request. New device and unusual location are examples in OWASP guidance, not a list of verified WEIMI detection features.
Notification: identify the out-of-band channel, intended recipient and observable outcome. A message displayed only inside the changing session does not, by itself, describe an out-of-band notice.
High-value account policy: ask whether step-up verification or a delay applies and who defines it. Do not invent a mandatory duration or demand that every low-privilege viewer follows the same rule as an administrator.
Recovery ownership: document who handles an unavailable old factor and which process applies. A purchasing team should not approve an informal bypass simply to make a device migration convenient.
Evidence hygiene: screenshots and handover records should identify the case and result while omitting secrets. Confirm who retains the evidence and who can review unresolved outcomes.
The three real WEIMI listings below form a public-description retail shortlist. “Best” refers to candidates for a buying task, not a ranking of account security. MFA replacement, risk checks and notifications remain unverified for every candidate.
PUBLIC CANDIDATE 1 · FACTOR CHANGE UNVERIFIED
The single-door AI vision fridge page describes camera-based packaged-goods checkout, five shelf levels with five baskets and top screen or lightbox options. Confirm cooling. It does not prepare juice. Camera recognition of selected goods does not establish human operator authentication; ask who manages any enrolled factor in the actual service quotation.
PUBLIC CANDIDATE 2 · FACTOR CHANGE UNVERIFIED
The WM22 listing describes a 21.5-inch touchscreen, inventory-related management and cooling. Spiral, conveyor, direct-push or hanging arrangements are options to confirm for the order. Conflicting generic capacity and energy figures are excluded. Ask which operator service accompanies the machine and what evidence authorises a factor replacement.
PUBLIC CANDIDATE 3 · FACTOR CHANGE UNVERIFIED
The dual-cabinet listing shows a main display and an additional visible spiral stock area. Confirm the quoted arrangement. Shared software, independent cooling, a second display and capacity are not established. Ask the provider to name the responsible account service rather than infer identity-management ownership from the station’s physical layout.
| Public hardware candidate | Confirmed description | Separate account evidence |
|---|---|---|
| Single-Door AI Vision Smart Fridge for Packaged Drinks | Packaged-goods camera checkout | Who controls operator-factor replacement? |
| WM22 Snacks and Drinks Vending Machine | Touchscreen and inventory-related management | What proof and notice accompany a change? |
| Two Cabinets, More Choice: Snack & Drink Vending Station | Main display and additional spiral stock area | Which service owns the enrolled operator factor? |
Keep the hardware fit and the factor-change responsibility visible in the quotation. The number of screens or cabinets does not identify the organisation responsible for the enrolled operator factor.
Hypothetical migration-review budget, not a supplier price or predicted return. Assume five hours to map enrolment responsibilities at USD 90/hour, six hours for a controlled provider demonstration at USD 90/hour and three hours to write the handover procedure at USD 90/hour.
| Assumed task | Calculation | Illustrative cost |
|---|---|---|
| Responsibility mapping | 5 × USD 90 | USD 450 |
| Provider demonstration | 6 × USD 90 | USD 540 |
| Handover procedure | 3 × USD 90 | USD 270 |
| Total | 450 + 540 + 270 | USD 1,260 |
The invented USD 1,260 total excludes replacement devices, subscriptions, identity-provider charges, security assessment and implementation work. Request actual configuration and service quotations before budgeting.
At an assumed USD 18 contribution per sale, USD 1,260 represents 70 sales of contribution before other costs. This illustrates budget scale rather than forecast demand or payback. No incident probability, prevented loss or measured time saving is used to justify the purchase.
For a planned phone migration with the old factor available, evaluate the normal replacement route and its existing-factor proof. Keep the new device enrolment and the notification outcome in the same redacted case record.
For a privileged fleet administrator, have IT review the applicable risk checks and any step-up or delay policy. A convenient migration demonstrated on a viewer account may not establish the administrator policy.
For a lost device, request the recovery procedure and authorised owner before operational access becomes urgent. This is a different scenario from proving possession of an existing factor; neither a supplier promise nor an informal support message establishes completed recovery.
For an externally managed identity service, ask the parties to explain where replacement occurs and who sends the notice. Do not infer that a vending dashboard controls a factor enrolled elsewhere.
A procurement schedule can name the operator service, replacement owner, required evidence and notification route. This avoids leaving a future phone migration as an undocumented support assumption.
A commissioning exercise can use a designated test factor and test account to demonstrate the agreed normal path. The record should distinguish observed steps from provider explanations and cases deferred for later review.
A team handover guide can direct operators to the approved migration or recovery route. It should explain whom to contact when the old factor is unavailable without documenting live recovery codes. These are proposed workflows, not customer case studies or completed WEIMI security demonstrations.
OWASP advises against relying solely on the active session and recommends reauthentication with an existing enrolled factor before changes.
Ask for the separately approved recovery process. The normal existing-factor replacement path does not explain lost-factor recovery by itself.
A notification communicates a change. It is separate from the evidence required to authorise that change.
OWASP suggests considering delays or step-up verification for high-value accounts. Define the applicable policy with the responsible provider and IT team.
No. These are public hardware candidates, and no authenticator replacement or account recovery was tested.
No. Use a redacted test-case record and keep credentials, recovery codes and enrolment secrets out of shared evidence.
Select hardware for the actual retail task, then specify how the quoted operator service authorises an enrolled-factor change. Require a clear distinction between active-session status, existing-factor proof, risk checks and notification.
Keep planned replacement and lost-factor recovery as separate acceptance items. Record the demonstrated scope and unresolved evidence. A new phone that successfully signs in does not alone establish how the change was authorised or whether the legitimate user was notified.
Share the intended operator roles, identity-service arrangement and device-migration needs. Request the administration-service responsibilities and available factor-change evidence alongside the vending equipment quotation.
Research: OWASP Multifactor Authentication Cheat Sheet, Changing MFA Factors, read 11 October 2026. WEIMI public hardware evidence reviewed 10 October 2026. No candidate authentication feature, independent security test or compliance outcome is asserted.
