CERT-In Crypto Warning: 5 Security Checks Expose the Limits of Personal Protection

CERT-In has warned that AI-assisted attackers are targeting Indian financial platforms, including cryptocurrency exchanges, despite earlier remediation efforts. The CERT-In crypto warning, issued November 4, 2026, shifts attention beyond convincing scam messages to the infrastructure holding customer assets. For Indian crypto users, five security checks matter, but their limits matter just as much.

The central conflict is personal control versus platform dependence. A user can protect an exchange login and still depend on systems they cannot inspect. Moving assets into self-custody, where users control their own signing keys, changes that dependence while introducing different responsibilities.

The FBI’s earlier attribution of the Bybit theft to North Korea provides a historical reference for institutional exposure. It does not establish an AI connection to that incident. The current Indian advisory stands on its own, raising questions about what customers can verify and what providers must demonstrate.

The CERT-In crypto warning makes custody the first check

India’s Computer Emergency Response Team published its latest advisory on November 4, updating an October warning about unauthorized financial transfers. The notice identifies cryptocurrency exchanges among affected financial service categories. It also describes theft of wallet keys and calls the campaign active.

CERT-In attributes the activity to a threat actor it calls CRAFTY FALCON. According to its AI-assisted attack advisory, attackers have targeted institutional systems and used payment interfaces to move funds. Some organizations reportedly faced renewed attacks after incomplete remediation.

The first security check is identifying who controls the assets, because account protection and custody protection solve different problems.

A custodial exchange controls the infrastructure used to hold and transfer customer assets. Customers generally access their holdings through accounts governed by the provider’s systems. Their security settings help protect account access, but they do not reveal how institutional signing keys are protected.

That distinction makes the warning consequential for people who never interact with unfamiliar tokens or unsolicited investment messages. A careful customer remains exposed to decisions made inside a provider. Strong personal habits cannot substitute for the provider’s operational controls.

The immediate question is whether users understand their custody arrangement. A familiar app interface can hide materially different responsibilities. An exchange balance, a wallet controlled by the user, and an investment dashboard should not be treated as interchangeable evidence of asset control.

Customers can examine published custody explanations, withdrawal procedures, incident notices, and support documentation. These materials cannot prove that infrastructure is secure. They can show whether a provider explains its responsibilities clearly enough for customers to make informed decisions.

A provider that describes only customer password hygiene leaves an important question unanswered. Its customers also need to understand the safeguards surrounding institutional transfers. Marketing language about security does not explain which actions require independent approval or how suspicious activity receives attention.

Self-custody transfers responsibility rather than eliminating it. Users gain direct control over signing credentials, but they also become responsible for protecting and recovering them. Someone who cannot safely manage recovery information should recognize that limitation before making hurried changes.

The practical implication is deliberate exposure management. Users should know which assets depend on a provider and which depend on their own procedures. Decisions made under pressure from a warning can create fresh mistakes if the destination or recovery process remains unfamiliar.

The CERT-In crypto warning therefore challenges the idea that a personal checklist can certify an entire financial relationship. The checklist remains useful, but its first task is drawing the boundary. Customers need to know where their control ends before deciding what additional protection accomplishes.

Stronger logins protect customers, not an exchange’s entire balance sheet

The second check concerns the exchange account and the email account used to recover it. These access points deserve attention together. Protecting the visible login while overlooking recovery settings creates an incomplete picture of account security.

Multifactor authentication requires additional evidence beyond a password, such as a device or authentication code. However, different implementations resist different attacks. A security setting labeled “two-factor authentication” does not explain whether a convincing fake website can capture the information a user supplies.

CISA’s phishing-resistant authentication guidance identifies FIDO/WebAuthn authentication as a widely available phishing-resistant approach. This technology binds authentication to the legitimate service. Where supported, compatible passkeys or security keys offer a different defense from manually entered codes.

A stronger login reduces account takeover exposure, but it cannot repair compromised systems inside the platform.

That limitation should shape how exchanges communicate security improvements. An announcement about passkey support is relevant to customer access. It does not independently establish that institutional assets, internal approvals, or software deployment systems received equivalent protection.

Customers should distinguish between the authentication method they selected and the complete recovery process. Recovery exists to restore legitimate access when something goes wrong. It therefore deserves scrutiny alongside the primary login, rather than treatment as a secondary administrative detail.

For example, a customer might secure an exchange with a passkey while leaving the associated email poorly protected. The exchange setting would still be valuable. However, the user would need to examine what account changes remain possible through email or other recovery channels.

The same distinction applies to active sessions and connected devices. A successful login is only part of an account’s lifecycle. Users should understand which existing devices retain access and how the service communicates changes, particularly after a suspected compromise.

These are questions about the actual service in use. Authentication options vary, and users should consult the provider’s current documentation. It would be misleading to assume that every exchange supports identical methods or handles recovery in the same way.

Provider comparisons should therefore examine behavior rather than brand familiarity alone. One service might explain recovery restrictions clearly, while another emphasizes convenient access. Those differences affect the customer’s ability to understand and manage account exposure.

The tradeoff is practical. Security that users cannot recover or maintain can lead to lockouts and risky workarounds. Convenience without clear boundaries can leave them unable to recognize which requests deserve independent verification.

For exchanges, the pressure is to connect safer access with understandable recovery. For users, the task is narrower: verify the protections actually available and understand their limits. Neither side benefits from presenting an authentication feature as a blanket guarantee.

This is where the institutional warning changes the conversation. Personal login improvements remain worthwhile, but they address only one route to loss. Customers should expect providers to discuss institutional safeguards with the same clarity they bring to account settings.

AI impersonation puts independent verification ahead of visual confidence

The third check is how a user verifies an unexpected instruction involving assets. This includes requests that appear to come from support staff, colleagues, relatives, or investment contacts. The relevant question is whether the instruction has an independently established origin.

Generative AI produces text, images, audio, or other content from learned patterns. Its role in fraud does not require breaking a wallet’s cryptography. It can help an attacker make an existing deception appear more credible.

The FBI’s December 2024 warning described criminals using synthetic profiles, investment content, cloned voices, and generated video. Its AI fraud warning also recommends independently contacting organizations rather than trusting an incoming caller’s identity. The warning predates the current Indian campaign.

A realistic voice or polished message should support a conversation, not authorize a financial action.

The analytical distinction is between apparent authenticity and verified authority. A caller can sound familiar without having permission to redirect assets. A message can contain accurate personal details without coming from the organization it names.

Consider an illustrative scenario involving an exchange customer. A caller claims an urgent security incident requires moving assets to a replacement address. The customer’s decisive question should concern independently verified instructions, rather than whether the voice sounds convincing.

That example is hypothetical, not an incident attributed to CRAFTY FALCON. It shows why institutional warnings can become material for unrelated impersonation attempts. A real security announcement does not authenticate every message that invokes it.

The safer boundary is a contact route established separately from the incoming request. Opening a familiar app or using previously verified support details changes who controls the conversation. Following the caller’s link preserves the attacker’s ability to define the next step.

This approach also helps when no AI is involved. Users do not need to determine which model generated a message before withholding approval. Verification procedures should work against ordinary impersonation and synthetic media alike.

The distinction matters for employers and knowledge workers managing business funds. A recognizable executive’s face does not replace an approval process. Financial authority needs to remain attached to established roles and procedures, even when a conversation appears personal.

It also matters for families sharing investment decisions. An urgent request creates emotional pressure that a technical explanation alone may not resolve. Agreeing on independent confirmation procedures beforehand makes the response less dependent on judgment during a stressful conversation.

There is no evidence in the cited material that every suspicious crypto message uses AI. Nor does an AI label measure the credibility of an individual request. Treating all fraud as a new technical phenomenon can distract from the authorization decision underneath it.

For platforms, this creates a communication challenge. Their legitimate security instructions should be easy to verify through established channels. Customers should not need to trust an unsolicited message to discover whether that same message is authentic.

Wallet control changes the risk, but approvals still matter

The fourth check concerns recovery information and the permissions a wallet grants. This becomes especially relevant when customers consider reducing exchange dependence. Self-custody changes who can authorize transactions, but it does not make every action safe.

A recovery phrase is a set of words used to restore access to a wallet’s signing credentials. Anyone handling that information needs to understand its role before storing or sharing it. A request to disclose it deserves a different response from an ordinary account question.

Ethereum’s wallet security guidance advises users to protect recovery phrases, verify transaction details, and avoid unnecessary spending permissions. It also explains the value of hardware wallets, devices designed to keep signing keys separate from an internet-connected computer.

Control over a wallet is valuable only when users preserve control over both its credentials and its authorizations.

A smart contract is software executed on a blockchain. Some interactions request permission to spend particular tokens, rather than immediately transferring the full balance. That distinction helps explain why reviewing an approval matters even when the screen does not resemble a conventional payment.

A wallet connection and a spending authorization are not interchangeable actions. Users need an interface that explains what they are being asked to permit. Confusing those steps makes it harder to assess the consequences of a seemingly routine interaction.

The underlying concern is understandable authority. A user should be able to identify the asset, recipient, and permission involved before approving an action. If the request remains unclear, the presence of a familiar logo does not resolve that uncertainty.

Hardware wallets can strengthen key protection, but they should not become a reason to approve unfamiliar requests. A device’s protective role depends partly on how the user operates it. Keeping credentials separate does not make the meaning of an authorization irrelevant.

This also explains why moving assets during a scare requires care. A rushed migration can combine unfamiliar software, new recovery information, and an unverified destination. The move should be evaluated as a security-sensitive process in its own right.

Comparing self-custody products with exchanges requires acknowledging different failure boundaries. An exchange can centralize support and operational responsibility. A self-custody wallet gives the user more direct authority while demanding more direct responsibility for recovery and signing.

Neither arrangement deserves an unconditional safety label. The useful comparison concerns which risks a particular user can understand and manage. A technically experienced person and an occasional buyer might reach different decisions without either ignoring security.

For AI product users, recovery phrases should remain outside general writing and knowledge workflows. A tool’s usefulness for organizing research does not create a reason to upload signing credentials. Keeping ordinary documentation separate from financial secrets is a practical boundary.

The broader lesson is about reducing unnecessary authority. Users should question permissions they do not understand, just as institutions should question excessive internal access. The two operate at different scales, but both depend on controlling what an approved action actually enables.

Incident readiness is the fifth check, and recovery remains uncertain

The fifth check is whether users know how to respond before an incident occurs. Preparation matters because a suspected compromise creates confusion about devices, accounts, transactions, and support channels. Improvising every decision makes independent verification harder.

India’s financial fraud reporting framework includes the 1930 helpline and the National Cybercrime Reporting Portal. The Ministry of Home Affairs identifies these as routes for reporting financial cyberfraud. Reporting should accompany contact with the relevant financial provider.

A documented response route improves coordination, but no reporting channel guarantees that crypto assets will be recovered.

An exchange account incident and a self-custody incident require different information. The former involves the provider’s account systems and internal response. The latter can involve wallet addresses, transaction records, permissions, and the condition of the user’s signing environment.

Users should preserve the evidence available to them. That can include messages, transaction identifiers, addresses, account notifications, and the sequence of events. A clear record helps distinguish what actually happened from assumptions formed during the initial panic.

Evidence handling should avoid spreading secrets further. A support conversation may need transaction details without needing recovery words. Users should separate information that identifies an incident from information that grants authority over remaining assets.

The response route also needs independent verification. A new contact offering immediate recovery should not inherit trust simply because the situation feels urgent. The same standards applied before a loss remain relevant afterward.

For providers, incident communication should distinguish confirmed findings from continuing investigation. A statement that service has resumed does not, by itself, answer every question about the original compromise. Customers need clarity about affected functions and any actions required from them.

That distinction is central to interpreting the CERT-In crypto warning. The notice describes continuing institutional exposure, while customers often receive information through brief operational updates. Availability and security are related, but they are not identical claims.

There are also important limits to the public evidence. The advisory does not establish that every Indian crypto exchange has been compromised. It does not provide a platform-by-platform safety ranking or a complete public accounting of customer losses.

The AI attribution requires similar care. CERT-In reports AI-assisted activity, but the public notice does not independently demonstrate every tool’s contribution to every incident. Readers should preserve that attribution rather than turn it into a claim that AI alone caused each compromise.

This uncertainty does not make the warning irrelevant. It changes the questions worth asking. Users need practical information about their own provider, while investigators need evidence that supports specific technical conclusions.

Incident readiness is therefore a coordination check rather than a promise of rescue. Customers should know their legitimate reporting routes and preserve usable records. Platforms remain responsible for explaining what happened within the systems they operate.

The next test is whether providers make protection observable

The CERT-In crypto warning creates an immediate reason to review exposure. Over the next several months, the stronger test will be whether public information becomes more useful. Repeated reminders to customers will not answer questions about institutional safeguards.

The most meaningful follow-up is evidence that providers have reduced the risks customers cannot manage themselves.

The first signal to watch is specific remediation disclosure. Providers can explain which categories of systems or processes they reviewed without exposing sensitive implementation details. The useful information concerns completed changes, their scope, and how the organization evaluates whether they remain effective.

An independent assessment would strengthen that information when its scope is clear. The phrase “security reviewed” says little without context about what was examined. Customers should distinguish an assessment of a particular component from a broader conclusion about custody operations.

More detailed disclosure would strengthen confidence that the warning produced concrete institutional responses. Vague assurances would leave the original uncertainty largely intact. Neither silence nor polished wording alone establishes whether a particular provider is compromised.

The second signal is whether customer protections become clearer in daily use. Authentication choices, recovery procedures, and explanations of withdrawal controls can be evaluated directly. A provider’s documentation should help users understand available safeguards without requiring them to interpret promotional language.

The strongest improvements would connect convenience with understandable limits. Customers need to know what an account protection feature covers and what it leaves to institutional systems. That clarity would support better decisions even when providers make different design choices.

A focus exclusively on customer passwords would weaken confidence in the breadth of the response. It would address an important issue while leaving custody questions unanswered. The public warning concerns more than the behavior of individual account holders.

The third signal is follow-up evidence about recurring incidents and attack attribution. Additional official findings could clarify affected functions, remediation failures, and the role of AI assistance. Those findings should be judged by their specificity, rather than the novelty of the threat label.

A repeat incident would require examining whether the underlying exposure remained unresolved. An absence of new public reports would be less conclusive. Reporting practices, investigation timelines, and disclosure decisions can limit what outsiders know.

This is also the point where international comparisons become useful. The FBI’s Bybit theft attribution provides an established example of a major exchange-level incident. It supplies context for institutional risk, while offering no proof about this Indian campaign.

The comparison should remain narrow. Different incidents can involve different access paths, controls, and evidence. Grouping them under an AI security label would obscure the distinctions customers and investigators need.

For Indian users, the durable decision is how much dependence they accept and what evidence informs that choice. Personal security features are visible and actionable. Institutional practices are harder to evaluate, which makes precise provider communication more valuable.

Review your custody arrangement, account access, verification habits, wallet permissions, and reporting routes before an urgent message forces a decision. Ask your provider questions that distinguish personal protections from institutional responsibilities. Keep verified contact details and ordinary incident records somewhere accessible, while keeping recovery phrases outside that documentation. If a request asks you to move assets, disclose secrets, or approve an unfamiliar action, verify its origin through an established channel. Use the CERT-In crypto warning to identify specific gaps rather than make a hurried migration. Which parts of your protection can you verify yourself, and which still depend on a provider’s explanation?