Innomerc Learn
English is the default.
Everyday Security

I Shared an OTP or Approved a Request

Act quickly on the account or payment the code was meant to authorize.

No experience needed4 min explorationReviewed
My learningNot started

One useful thing to do today

Tell the provider what action the message described and when it happened.

More everyday safety lessons

Choose your depth. Learn at your own pace.

Simple explanation

Understand it

Stop contact with the person asking for codes. Read the original message to identify the service and purpose. Do not send another code to “undo” the first one.

Contact the real provider through its official app or known number. If it was a banking or payment code, report possible fraud immediately. For an account, secure sign-in, review sessions and recovery settings, and revoke unfamiliar access using the provider’s recovery process.

Technical explanation

Under the hood

A code might complete a sign-in, enroll a device, reset a password or authorize a transaction. Expiry of the code does not terminate a session or reverse an action already completed. Scope the response to the actual challenge.

Practitioner explanation

Practitioner perspective

Review challenge metadata, factor changes, session issuance and transaction records. Preserve evidence without storing the code itself. Check for persistence through forwarding rules, newly registered authenticators or third-party grants.

See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

A code is permission, not just a number

Follow a real code request. Expiry does not undo a completed sign-in or payment.

Steps1. Reset request 2. Real code 3. Code forwarded 4. Action completed
Click a box or choose its name to learn what it means.
UnknownrequesterReadyYouReadyReal accountReadyUnknownrequesterReadyYouReadyReal accountReady
Ready to traceCode shared
Before you start · 4 stepsCode shared

Someone can trigger a real code and then deceive its owner into forwarding it.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • Unknown requester

    A person asking you to do something before you have verified who they are.

    Example: A message asks you to forward a sign-in code. Keep the code private and check the request independently.

  • You

    The person making the decision in this fictional example.

    Example: You decide whether to share information, approve a request or check it first.

  • Real account

    The actual account service, rather than someone impersonating it.

    Example: A sign-in code can authorize access to this account; forwarding it can give someone else that access.

Code shared

Someone can trigger a real code and then deceive its owner into forwarding it.

  1. Unknown requester Real account: Reset request. The requester starts an account-reset action.
  2. Real account You: Real code. The service sends you a code for that requested action.
  3. You Unknown requester: Code forwarded. The requester receives the code while it can still be used.
  4. Unknown requester Real account: Action completed. If accepted, the code completes the requested action.

Code kept private

An unexpected request is a reason to verify independently, not to forward the code.

  1. Unknown requester Real account: Reset request. The requester starts a reset you did not ask for.
  2. Real account You: Unexpected code. You read the action described by the service.
  3. You Real account: Direct review. You keep the code private and open official security settings.

Shared it already

Act on the purpose of the code; waiting for expiry does not reverse a completed action.

  1. You Real account: Official recovery. Contact the genuine provider and describe what was approved.
  2. Real account You: Secure access. Follow account or payment-specific recovery instructions.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Code shared

The requester receives the challenge.

1 / 3

Takeaway Expiry is not a reversal.

Read every step without animation

Wait for expiry

  1. Code shared. The requester receives the challenge.
  2. Action completes. A sign-in or approval succeeds.
  3. Code expires. The completed action can remain valid.

Expiry is not a reversal.

Provider contacted

  1. Stop contact. Do not send further codes.
  2. Identify purpose. Read the message’s action description.
  3. Recover + review. Ask the real provider to secure affected access.

The response follows the action that was authorized.

What could go wrong

Waiting for a shared code to expire leaves an already completed action unaddressed.

What you can do

  • Tell the provider what action the message described and when it happened.
  • Use the official recovery route if locked out and review connected devices after regaining access.

Common mistakes

  • Code expiry does not undo a payment or sign-in.
  • A caller asking for another code may be continuing the same scam.

Check your understanding

Does an expired OTP end a session already created with it?
Active recall: explain this idea in 30 seconds

Stop contact with the person asking for codes. Read the original message to identify the service and purpose. Do not send another code to “undo” the first one.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Read the editorial policy.

What comes next?

Something happened. What now?

Back to topic