Definition
2FA (Two-Factor Authentication) is an authentication method that adds a second verification factor in addition to a password, usually combining "something you know" (password) with "something you have" (phone, hardware key) or "something you are" (fingerprint, facial recognition). In the International IoT Cloud Platform (ICMP), 2FA works with OTP and IAM to enhance security for Global Dashboard, Partner Portal, and sensitive API access, meeting enterprise customer and compliance requirements.
Working Principle
2FA process: After the user enters their account password (first factor), the system requires a second factor for verification. Common methods include: OTP (one-time password) delivered via SMS Gateway or TOTP apps; hardware keys (such as FIDO2); biometrics. Once verification is successful, the user obtains a session or token, which allows access to protected resources. The ICMP platform can enforce 2FA in scenarios such as login, payments, and sensitive configuration changes, in conjunction with IAM role permissions and Audit Trail to form a complete security and auditing chain.
Use Cases
Typical scenarios include: Portal login — Global Dashboard, Partner Portal admin, Reseller login enforcing 2FA; Payments and sensitive operations — verification before operations such as Payment Gateway integration, bulk refunds, and Suspension of a large number of devices; High-privilege API calls — some sensitive RESTful API endpoints may require 2FA verification before obtaining a temporary token; Compliance requirements — meeting strong authentication requirements of PCI DSS, GDPR, etc.
Practice in ICMP
SimtoLink ICMP supports optional or mandatory 2FA. It supports OTP via SMS (through SMS Gateway) and TOTP applications (such as Google Authenticator). Integrated with IAM, 2FA policies can be configured for different roles and operations. Sensitive operations (such as payments or batch Suspension) can require a second verification. Combined with Audit Trail, 2FA verification events can be recorded, supporting security audits and compliance documentation.
Which Entrances the Second Factor Protects
Two-factor authentication requires two different kinds of evidence in the same confirmation. A common pair is a password only the person knows, plus a time-based code, an SMS code, or a hardware key only the person holds. What it strengthens is confirmation when a person enters a management capability. It is not the carrier authentication a device uses to join the network. A connectivity platform has at least two entrances to consider: signing in to the portal or the API, and sensitive actions after sign-in. Sensitive actions include bulk suspension, exporting a file that contains device or contact information, changing a tariff, and confirming a payment. Verifying only at sign-in leaves later actions inside a long session unprotected by the second factor.
Enable it only when every role that needs protection has a usable second factor, and when loss has a recovery flow of its own. Recovery must not be weaker than everyday sign-in, for example turning the factor off after a support call that checks nothing else. An unattended system call should not pretend to be a user who has already passed two factors. It should use a revocable service credential, with scope limited in the authorization protocol. A person’s session should confirm again before a high-risk action. Factor material must be protected by TLS and by access control while it is sent and while it is stored. The shared secret of a time-based code must not appear in clear text on a ticket.
Guarding Login and Leaving Sensitive Actions Open
A common error is to turn on two-factor authentication for everyone’s sign-in and then believe export, suspension, and payment are already safe. An attacker, or someone who simply makes a mistake, needs only a session that is already signed in, and those actions still run. Another error is to let the user choose “remember this device” with no expiry, so the second factor appears only the first time. A shared account plus two factors is also meaningless, because the code generator is held by several people and the audit trail cannot point to one person.
An SMS factor can lock an administrator out when international roaming or SMS delay is high, so another factor should be prepared in advance. Do not turn the policy off for the moment. Turning two-factor authentication off is itself a sensitive action. It needs confirmation with a factor that already exists, and it needs a record. A two-factor policy should list entrances: which roles need it at sign-in, which actions need it again, how long a session may last before it must be repeated, and who may recover a lost factor. Only after that list exists does it cover the operations that actually carry risk in connectivity management.
The second confirmation should happen before the action runs, not as a record added afterward. If bulk suspension, export, or payment confirmation has already been submitted to the back end, asking for a time-based code then is too late to withdraw a failed code. The confirmation window should be short. After it passes, only the one action already shown to the user may be completed. If the user changes the suspension scope or the amount, confirm again. Applying one confirmation to any later operation returns to a single factor after the confirmation.
A recovery method must not be easier for someone else to complete than the everyday factor. If backup codes are issued, limit how many there are, invalidate each after use, and tell the user at generation to keep them carefully. When a backup code is used, notify the account owner. Support must not turn two-factor authentication off after checking only a name or an email address. Turning it off needs an existing factor. When every factor is lost, follow the manual check agreed in advance, and keep a ticket. After recovery, the old time-based binding is invalid, so a lost phone cannot keep passing verification.
Remembering a device needs a maximum period, and it does not apply to sensitive actions. Sign-in may ask one time less within the agreed period. Export, suspension, and payment still need a fresh confirmation. When the period ends, or the user cancels it, the next sign-in returns to two factors. A public or shared browser should not be remembered. The policy page should show whether a role currently needs the factor at sign-in, for sensitive actions, or for both, so turning on only the sign-in switch is not mistaken for a complete policy.