Configuring LabVIEW Supervisor Approval with Mobile 2FA

After the fix, LabVIEW releases the protected action only after a named supervisor approves that specific request; duplicate, denied, stale, and replayed responses remain blocked. Build that behavior as a stateful approval workflow, using an offline HOTP code only when the supervisor can enter a code locally.

Reject the quick fixes first

The common shortcuts solve adjacent problems, not per-action approval. OAuth handles delegated authorization: an application receives permission to access a service without receiving the user's login credentials. Once an administrator authorizes or whitelists the application, later calls can run under that delegated authority without requiring the administrator to approve each machine action. That is the wrong control when every action needs a fresh human decision.

A dummy account login is another poor fit. It turns a machine approval into an account-authentication side effect, depends on a third-party login flow, and does not inherently bind the supervisor's response to the requested action. Logging out afterward does not correct that architectural mismatch.

Two HTTP POST operations followed by string stripping may prove connectivity, but they do not safely manage redirects, errors, duplicate requests, malformed responses, or interrupted sessions. HTTP messages are straightforward; the workflow around them is stateful.

Observed result	Likely cause	Corrective direction
The application runs without a new supervisor response	OAuth grants persistent application authorization	Use a transaction-specific approval record
The authenticator generates a valid code, but no remote approval arrives	HOTP provides an offline code, not mobile push messaging	Enter the code locally or add a reachable approval service
The first HTTP exchange works, but retries or redirects fail	The LabVIEW logic treats a stateful exchange as an isolated request	Implement explicit request states and validate every response
A previous approval can release another action	The decision is not bound to one request and consumed once	Use a unique request record and reject replay
The application waits indefinitely	No denied, expired, canceled, or communication-failure branch exists	Define terminal states and a site-approved expiry policy

Check what the supervisor must prove

Take the first reading from the operating requirement: does the control need authentication, authorization, or explicit approval?

• Authentication: establish that the responder controls an enrolled authenticator.
• Authorization: establish that the authenticated identity has permission to approve the action.
• Approval: record that the authorized person accepted this action at this time.

If authentication alone is sufficient, an HOTP implementation may fit. HOTP derives a one-time code from HMAC processing of a shared secret and a counter. It can operate without an Internet connection, but the verifier must hold the matching secret and maintain counter state.

If the requirement says a supervisor must approve a particular sequence, continue to the approval-workflow checks. A valid authenticator code proves control of an enrolled factor; it does not by itself prove that the supervisor reviewed the action, equipment context, or consequences. Bind the decision to a request that displays those details.

Check whether the approval path must work offline

Read connectivity at both endpoints when the request occurs: LabVIEW-to-service connectivity and supervisor-device-to-service connectivity.

• If the supervisor is physically present and can type a code into the station, use the offline HOTP branch. The LabVIEW system or a local verifier checks the code and records approval against the waiting request.
• If the supervisor must approve remotely on a mobile device, provide a reachable service. The service receives the operator request, presents it to the supervisor, and returns an allow or deny decision.
• If either endpoint is offline, hold the request without releasing the action. Resume status checks after communications return, or cancel it according to the plant's expiry policy.

An authenticator application can generate an offline code because code generation is local. It cannot deliver a remote acknowledgement without a communication path. Keep those two functions separate when selecting the design.

Next, test the loss-of-connection branch. If LabVIEW cannot distinguish pending approval from a failed status check, stop implementation and add an explicit communications-failure state. Loss of communications must never be interpreted as approval.

Check identity and authority separately

Read the identity returned by the authentication mechanism, then query whether that identity may approve the requested action. A generic success flag is not enough when several supervisors, roles, or protected actions exist.

For the HOTP branch, associate each enrolled secret with a supervisor identity. Protect the shared secret at rest and restrict access to the verifier. Never place the secret in operator-visible indicators, logs, exported configuration, or ordinary diagnostic messages.

For the network branch, make the supervisor authenticate to the approval service. The service—not the LabVIEW client—checks approval authority. LabVIEW submits the request and consumes the decision; it must not be able to claim that an administrator approved it.

If the supervisor can see only a login prompt and not the requested machine action, stop at this check. Present enough context to distinguish requests before accepting a decision. Otherwise, a genuine supervisor response can still approve the wrong operation.

Check the request state before writing HTTP code

Read the database entry for the current request. The entry needs a unique reference, the protected action, operator context, equipment context, creation time, current state, and—after response—the supervisor identity and decision. Add only the site-specific data required to distinguish and audit the action.

Use a one-way state model:

• Pending: created but not decided.
• Approved: an authorized supervisor allowed it.
• Denied: a supervisor rejected it.
• Expired or canceled: it may no longer release the action.
• Consumed: LabVIEW used the approval once.

When the operator requests the action, search for the current request before inserting another entry. A retry caused by a timeout must not generate several pending approvals. When the supervisor responds, update the same record. When LabVIEW checks again, release only an approved, unexpired, matching record, then consume it atomically so a second scan or reconnect cannot reuse it.

The request lifetime is a risk decision. Read the approved site policy or safety assessment rather than inserting an arbitrary timeout. Record enough timing information to determine whether the decision was valid when consumed.

Build the resolving LabVIEW path

Use LabVIEW's basic HTTP GET or POST capability for the single workflow selected above. Keep protocol transport, response parsing, and approval-state logic in separate subVIs so a parser failure cannot silently become an allow result.

1. Create a request record when the operator asks to run the protected sequence. Include the action and context the supervisor must review.
2. Send the request to the approval service. If no matching request exists, let the service insert it; if one already exists, return its current state.
3. Notify or display the request to the supervisor through the selected mobile or local interface.
4. Authenticate the supervisor and check that identity's approval authority.
5. Write an allow or deny decision to the original database record.
6. Have LabVIEW query that record until it reaches a terminal state or the approved site policy ends the wait.
7. Accept only a structured response whose request reference, action, state, and integrity checks all match the local request. Treat missing fields, parsing errors, unexpected redirects, and transport failures as non-approval.
8. For an approved result, consume the record and release exactly one execution. For every other result, keep the protected output blocked.
9. Record the request, decision, identity, and execution result in the audit trail without recording credentials or HOTP secrets.

If the chosen service uses a redirect-based OAuth flow for login, implement its full stateful HTTP sequence rather than copying a few observed messages. Use OAuth only to establish identity or delegated service access; retain the separate request record for the supervisor's per-action decision.

Verify the release branch before production use

Watch both the LabVIEW state and the server record while running each test. The protected action must remain blocked until every acceptance condition is true.

1. Create one request and approve it. Confirm the returned reference matches, the action runs once, and the record becomes consumed.
2. Create another request and deny it. Confirm the sequence remains blocked and the denial is recorded.
3. Resend the same creation message. Confirm the service returns the existing request rather than creating duplicate approvals.
4. Replay an old approved response. Confirm LabVIEW rejects the consumed or mismatched record.
5. Disconnect the network while a request is pending. Confirm communication loss produces no release and recovery resumes against the same request.
6. Restart LabVIEW and the approval service during separate pending tests. Confirm persistent state prevents a restart from converting pending into approved.
7. Return malformed JSON, an unexpected HTTP response, and a missing decision field. Confirm every case fails closed and produces a useful diagnostic.
8. For HOTP, test an accepted code, an invalid code, and reuse of the accepted code. Confirm a successful code cannot approve a second request.

Restore production only after the positive, deny, duplicate, replay, disconnect, restart, and parser-failure tests pass. Then schedule the permanent work: credential protection, audit retention, service monitoring, recovery procedures, and review of who may enroll or remove supervisor authenticators.

FAQ