The Scalegram panel asks for one thing at sign in: an email address. A code lands in the inbox a moment later, you type it, and the session opens. There is no password box, no reset link, no strength meter, no field that anyone can stuff with a list of credentials bought from a breach dump.
That choice is deliberate and it is worth explaining, because operators ask about it in almost every onboarding call. The panel holds the client list, the bot policy, the payment integrations and the ad connections for a business that runs on Telegram. Whoever gets in can send messages as the business. So the question is not whether an emailed code feels convenient. It is whether it produces a better outcome than the alternative for the people who actually use it.
What the code does and does not prove
A one-time code proves control of an email inbox at the moment of sign in. That is a narrower claim than a password, which proves knowledge of a secret that may have been chosen in 2019 and reused on four other sites. Narrow is the point. There is no stored secret to leak from our side, so a compromise of the panel database yields no credential that works anywhere else, including in the panel itself.
The code is short-lived and single use. It expires on a timer, it dies the moment it is redeemed, and a fresh request voids the previous one so that an old message sitting in a mailbox cannot be replayed later. Requests are rate limited per address, because an endpoint that emails anybody on demand is also an endpoint that can be pointed at somebody as a nuisance.
What it does not prove is that the person holding the inbox should have access. That is a separate decision, made when the account owner invites them, and it is governed by the per area rights described in team permissions. Authentication answers who. Authorisation answers what. Collapsing the two is how panels end up with one shared login that four people use.
The honest weakness: the inbox becomes the perimeter
Anyone who can read the email can sign in. That moves the whole security question upstream into the mail provider, which is a trade worth making only if the mail account is itself protected. In practice most business email now sits behind Google Workspace or Microsoft 365 with two step verification available, which is a stronger perimeter than a self chosen password on a small vendor's panel. The general argument is laid out in passwordless authentication.
The failure mode to plan for is a shared or forwarded mailbox. A support alias that four staff read is a four person key to the panel. Sign in should use an individual address per person, always, and the invitation flow makes that the path of least resistance rather than a policy nobody reads.
If your panel email forwards anywhere, that forwarding rule is now part of your access control. Audit it the same way you would audit a staff account.
Sessions, and the lockout that nobody designs for
After redemption the browser holds a signed session cookie with a fixed lifetime. Nothing about a one time code makes a session immortal, and treating the code as a once in a lifetime event is exactly how a laptop left in a co-working space stays signed in for a year.
Here is the trap we walked into and fixed, and it is worth naming because most teams building this hit it. A cookie can outlive the record it points to. The signature still verifies, the browser keeps presenting it, and the panel keeps treating the request as authenticated while every lookup behind it fails. The user sees a panel that loads and then breaks on each page, with no sign out button that helps, because the app never concludes the session is invalid. The fix is to treat a session whose backing record has gone as an unauthenticated request, clear the cookie in the response and send the visitor to the sign in screen. It sounds obvious written down. It is not obvious at three in the morning when a support message says the panel is blank.
Two related rules follow from that. Sign out must clear the record on the server as well as the cookie in the browser, or signing out is theatre. And a session must be revocable by the account owner from the team screen, because removing somebody's access has to take effect while they still have a live tab open.
Where this sits next to everything else
Sign in is one door among several. The panel also exposes public endpoints that no human logs into: payment notifications, Telegram webhooks, the tracking endpoints that fire pixel events. Those are protected by signature checks and origin rules rather than by a code in an inbox, which is a different set of controls covered in webhook handling. An emailed code has nothing to say about a machine to machine call, and pretending otherwise is how a login screen becomes the only security anyone reviews.
The bot side has its own boundary. Whatever a customer types into Telegram, the assistant's instructions, the account's keys and other people's details are stripped before a reply goes out, which is a message layer control rather than an access control.
Should you build it this way
For an internal panel used by a small team, yes. The support load drops because there are no password resets, the breach surface drops because there is no password store, and the onboarding is one screen instead of three. For a consumer product with millions of accounts and users on patchy email delivery, the calculus is different and the deliverability cost is real. Codes land in spam, corporate filters delay them, and a login that depends on mail arriving in ten seconds will occasionally not.
We accept that cost for Scalegram because the population is small, known and invited. If your users cannot reliably receive your mail, an emailed code is the wrong front door no matter how clean the security story reads.
"A password box is a liability you have to defend forever. If the only credential is a code that dies in minutes, most of the attacks you were worried about have nothing to aim at."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Scalegram signs in with a short-lived emailed code, so there is no stored password to leak, reuse or reset.
- The code proves control of an inbox at that moment, which makes the mail account the real perimeter and rules out shared aliases.
- Sessions still expire, sign out must clear the server record, and a cookie whose session record has gone must be rejected rather than half accepted.
- Machine endpoints such as payment notifications and Telegram webhooks are protected by signatures and origin rules, not by the sign in code.
Frequently Asked Questions
Is an emailed code less secure than a password?
It removes the stored secret, which is the thing that leaks in most breaches, and it removes password reuse. It also moves the risk into the email account, so it is stronger than a password only if that mailbox is itself protected.
What happens if the code does not arrive?
Request another one, which voids the previous code. Check spam and any corporate filter. Because delivery is the weak link in this design, an address that cannot reliably receive mail is a poor choice for panel access.
Can two people share one login?
They should not. Each person gets their own invited address with their own rights per area, so removals and audit trails mean something. A shared alias turns one login into several keys.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.