Two-Factor Authentication on the E-Way Bill Portal

2FA on the e-way bill portal means your username and password are no longer enough to log in: NIC also asks for a one-time code, which you can receive by SMS, generate in the NIC-GST-Shield app, or read in Sandes. It was introduced in phases from 2023 onwards based on annual aggregate turnover and now applies to every user of the e-way bill and e-invoice systems, sub-users and enrolled transporters included. Crucially, it applies to interactive portal logins only — API and GSP integrations authenticate a different way and are not affected.

What 2FA on the e-way bill portal actually is

The e-way bill system has always been a single-factor login: a username and password tied to a GSTIN, plus a captcha. That is a weak arrangement for a system that authorises the movement of goods worth crores every day, and shared passwords were the norm in most transport offices — one login circulated among a dispatch clerk, a supervisor and whoever was on the night shift. Two-factor authentication closes that gap by requiring something you have (a phone, or an app on it) in addition to something you know.

One detail catches people out repeatedly: the e-way bill and e-invoice portals run on the same NIC credential base. Registering for 2FA on the e-way bill side automatically applies it on the e-invoice side too, and vice versa. There is no separate switch to flip, no second OTP channel to configure. If you are subject to mandatory e-invoicing and generate e-way bills as well, expect the same login experience across both.

The three OTP channels

NIC offers three ways to receive the second factor. You are not locked into one — at the OTP prompt you can pick whichever channel is available at that moment, which matters more than it sounds when a warehouse has no mobile signal.

Channel	How it works	Where it fails
SMS	NIC sends a code to the mobile number registered against that user account.	Poor network coverage, DND and spam filters, operator delays, or a stale number on the user record. The single most common cause of "I can't log in" complaints.
NIC-GST-Shield	A dedicated NIC app that generates a time-based code on the device itself. Once registered against your account, it needs no network connection at all — it just needs the phone's clock to be correct.	Device time drift. If the phone's date and time are not set to automatic, the generated code will not match and every attempt will be rejected.
Sandes	The Government of India's own instant messaging app. The OTP arrives as a message inside Sandes rather than as an SMS.	Requires the app installed and the account set up on the same registered mobile number, plus a data connection.

How to turn on 2FA for e way bill login

Registration is done from inside the portal by the main user for the GSTIN, and it takes about a minute.

1. Log in to the e-way bill portal at ewaybillgst.gov.in with the main user credentials for the GSTIN.
2. Open the two-factor authentication section from the main menu and choose the registration option.
3. Confirm the registration. From your next login onwards, the portal asks for a third field — the OTP — after the username and password.
4. Install NIC-GST-Shield from the link provided on the portal and register it against the same account, so you have a channel that does not depend on SMS. Sandes is the alternative if your organisation already uses it.
5. Register the machines you routinely work from as trusted systems, covered in the next section.
6. Walk each sub-user through the same OTP-channel setup, and check that the mobile number stored against each sub-user record is current.

Menu labels on the NIC portals move around between releases, so treat the wording above as a description of the path rather than an exact transcript. If the option is not where you expect it, the current advisories listed on the e-way bill portal home page are the authoritative reference.

Registering trusted systems

The obvious objection to 2FA is that a busy dispatch desk generating fifty e-way bills a day does not want an OTP round trip on every login. NIC's answer is trusted-system registration: after you have completed a 2FA login, you can tell the portal to remember the system you are using. Subsequent logins from that same machine and browser skip the OTP prompt and behave much as they did before.

A few things to understand about how that trust is scoped:

• It is tied to the browser as well as the machine. Register in Chrome and then log in through Edge on the same desktop, and you will be asked for an OTP again.
• It depends on local browser state. Clearing cookies and site data, using a private window, or a machine-imaging refresh will drop the registration and you will need to re-register.
• It is per user account. Registering the dispatch desk for one sub-user does not register it for the others who share that terminal.
• You can register more than one system, which is what you want if the same person generates bills from a desktop at the plant and a laptop at head office.

Treat the trusted-system list the way you would treat any access list: review it when someone leaves, and deregister machines that have been retired or reassigned. A trusted system is, by design, a machine that no longer needs the second factor.

How the rollout worked, by turnover slab

NIC did not switch 2FA on for everyone at once. It was phased by annual aggregate turnover, starting with the largest taxpayers — the same sequencing logic used for e-invoicing — and stepping down through progressively smaller turnover bands until it covered all users. Large taxpayers were brought in first from 2023, mid-sized taxpayers followed, and the final phase extended the requirement to every taxpayer and user of the system regardless of turnover.

For anyone reading this now, the practical position is simple: the phasing is finished and 2FA applies to you. The only reason the slab history still matters is reconciliation — if you are auditing why a particular login stopped working on a particular date, or why one group entity was prompted months before another, the turnover band that entity fell into is usually the explanation. Aggregate turnover here is computed PAN-wide, not per registration, so a small state registration under a large PAN was pulled in at the same time as its larger siblings.

Sub-users, transporters and shared logins

This is where 2FA bites hardest in practice, because it exposes how loosely most organisations manage e-way bill access. The OTP is delivered to the mobile number recorded against the user account being used. Not the main user's number, not the authorised signatory's number on the GST registration — the number on that specific sub-user record.

Three consequences follow, and all three tend to surface on the same morning:

• Stale sub-user numbers stop working. Sub-users created three years ago with an employee's personal number will send OTPs to someone who left. Audit the sub-user list and correct the numbers before you rely on 2FA in production.
• Shared credentials stop being practical. If four people were using one login, the OTP lands on one phone and the other three are stuck. The fix is not to circulate the phone, it is to create proper sub-users — which is what the system intended all along.
• Enrolled transporters are in scope too. A transporter operating on a TRANSIN enrolment rather than a GSTIN logs in the same way and needs the same OTP setup. If your consignor process depends on a transporter updating Part B, confirm they have made the change, because a transporter locked out of the portal is your delayed consignment. Our guide to who generates the e-way bill and when covers where that handover sits.

The one genuinely good thing about this: after the clean-up, you have an accurate map of who can authorise goods movement under your GSTIN. That list is worth keeping in your periodic compliance review rather than rediscovering it the next time NIC changes something.

How 2FA interacts with API and GSP access

Short answer: it does not. Two-factor authentication is an interactive-login control. It exists to stop someone with a stolen password from sitting down at a browser and generating e-way bills. API access is a different authentication path entirely, and there is nobody at a keyboard to type an OTP into.

If you generate e-way bills programmatically, you do it through a GSP or an ASP built on one, using API credentials created specifically for that purpose on the e-way bill portal. Those credentials are separate from your web login, and the security model around them is built from different parts:

• A distinct API username and password created under the API registration section of the portal.
• IP whitelisting, so calls are accepted only from the addresses you have registered.
• The GSP's own authentication layer — client ID and secret — sitting in front of the NIC endpoints.
• Session tokens with a defined validity, refreshed by the integration rather than by a human.

So an ERP that pushes e-way bills over an API kept working through the 2FA rollout without any change. What did change is the fallback: if the integration fails and somebody needs to raise a bill manually on the portal at 11pm, that person now needs a working OTP channel. Make sure the people on your escalation rota can actually log in, because discovering an OTP problem during an outage is expensive.

Common failure modes

Most 2FA support tickets fall into a handful of buckets, and almost all of them are configuration rather than outage.

Symptom	Usual cause and fix
No SMS arrives	Wrong or outdated mobile number on the user record, or carrier filtering. Correct the number on the portal and switch that user to NIC-GST-Shield.
NIC-GST-Shield codes are always rejected	The phone's clock is off. Time-based codes are computed from the device clock, so set date and time to automatic and try again.
OTP asked for on every login despite registering the system	Different browser, private window, or cookies cleared by policy. Register from the browser actually used, and check whether IT is wiping browser state on logout.
One sub-user can log in, another cannot	Trusted-system registration and OTP channels are per user account. Each sub-user has to complete their own setup.
Login works on e-way bill but not e-invoice	Usually a trusted-system registration done on only one of the two portals, not a 2FA registration problem — the underlying 2FA registration is shared.
Cannot generate bills at all, OTP fine	Not a 2FA issue. Check whether e-way bill generation has been blocked for non-filing of returns, which is a separate mechanism tied to your return filing status.

That last row is worth dwelling on, because the two get conflated constantly. 2FA controls whether you can log in. Return-filing-based blocking controls whether you can generate a bill once you are in. A vendor who tells you their e-way bill "isn't working" may be describing either — and if it is the second, that is a signal about their compliance health, not their IT. Checking a counterparty's filing status and registration state before you rely on their paperwork is exactly the sort of thing worth automating; our notes on vendor verification in accounts payable cover how that fits into a payment run.

Frequently asked questions

Is 2FA mandatory for the e-way bill portal?

Yes. NIC rolled two-factor authentication out in phases against annual aggregate turnover and it now applies to all e-way bill and e-invoice portal users, including sub-users and enrolled transporters. Check the latest advisory on ewaybillgst.gov.in if you are unsure which phase your GSTIN fell into.

What are the three ways to get the e-way bill OTP?

An SMS to the mobile number registered against that specific user account, a code from the NIC-GST-Shield app, or a message in Sandes, the government instant messaging app. NIC-GST-Shield is the most reliable of the three because it generates the code on the device itself and does not need mobile network coverage.

Does 2FA break my e-way bill API integration?

No. Two-factor authentication applies to interactive logins on the web portal. API access is authenticated with separate API credentials, usually held by your GSP or ASP, and it does not present an OTP prompt because there is nobody sitting at a screen to type one in. Your API username, password and IP whitelisting continue to work as before.

Do I have to enter an OTP every single time I log in?

Not if you register the system you work from. The portal has a "Register Trusted System" option that remembers the machine and browser you use, so routine logins from that system skip the OTP step. Log in from a different machine, a different browser or after clearing cookies and the OTP prompt comes back.

Do I need to enable 2FA separately for e-invoicing?

No. The e-way bill and e-invoice systems run on the same NIC credential base, so registering for 2FA on one side covers the other. The same OTP channel and the same trusted-system registration apply to both.

My sub-user is not receiving the OTP. What is wrong?

The OTP goes to the mobile number stored against that sub-user account, not the main user's number. If the sub-user was created years ago with a number that has since changed, or with the main user's number by mistake, update the sub-user record on the portal first. NIC-GST-Shield sidesteps the problem entirely because it does not depend on SMS delivery.