AES-256-GCM: How Secrets Should Be Stored.

Think about what your CRM knows. Not the client data — the keys. The API credentials that can instruct your payment processor to move money. The secrets that authenticate against your KYC provider. The passwords that administer your trading platform bridge. Whoever holds those strings is your firm, as far as every connected service is concerned. And they have to be stored somewhere.

How they're stored is one of the least visible and most consequential engineering decisions in your entire stack. In the Singuard CRMs, payment keys, integration secrets and platform passwords are encrypted at rest with AES-256-GCM. This article unpacks what that sentence actually means, why each part of it matters, and how to interrogate any vendor who can't say the same.

The Threat: Data at Rest Outlives Every Other Defense

Security discussions usually focus on data in transit — TLS, padlocks, phishing. But databases have a longer, quieter life: backups get copied, snapshots get archived, disks get decommissioned, staging environments get forgotten. A secret stored in plaintext is exposed in every one of those copies, forever. The breach doesn't need to happen on your production server on a bad day; it can happen to a two-year-old backup nobody remembers.

Encryption at rest changes what a leaked copy is worth. If an attacker obtains the database file but not the encryption keys, they hold ciphertext — noise. The blast radius of an entire class of failures collapses from "our processor credentials are public" to "someone has a very large random number."

Decoding AES-256-GCM, One Term at a Time

• AES — the Advanced Encryption Standard, the symmetric cipher standardised by the U.S. NIST and used across banking, government and defense for over two decades. It is the most scrutinised cipher in existence; nobody serious deviates from it for data at rest.
• 256 — the key length in bits. A 256-bit keyspace is beyond any brute-force attack that classical hardware could mount in geological time. This is the "bank-grade" strength tier, and the difference between it and weaker legacy choices costs nothing at modern CPU speeds.
• GCM — Galois/Counter Mode, and this is the part practitioners actually check. GCM provides authenticated encryption: alongside confidentiality, every ciphertext carries an authentication tag that is verified on decryption. If even one bit of the stored data has been altered — by corruption, or by an attacker attempting to tamper — decryption fails loudly instead of silently returning corrupted plaintext.

That last property is why "AES-256-GCM" is a meaningfully stronger statement than "AES-256." Older unauthenticated modes can be manipulated by attackers who flip ciphertext bits without knowing the key — a family of real, exploited attacks. GCM closes the category: your secrets are not just unreadable, they're tamper-evident.

What Should Live Encrypted — And How It Should Behave

In the Singuard CRMs the encrypted-by-default set covers exactly the strings whose theft is catastrophic:

• Payment keys — the credentials behind your card and crypto processors, connected via the one-click PSP integration. These can authorise refunds and disbursements; they are the crown jewels.
• Integration secrets — API credentials for KYC providers, marketing platforms and webhook signing. Individually smaller, collectively an identity kit for your firm.
• Platform passwords — the credentials behind trading-platform bridges, which reach the system where trader accounts actually live.

Storage is only half the discipline; handling is the other half. Well-designed systems treat secrets as write-only from the operator's perspective: you paste a key into configuration once, and thereafter the interface shows a masked placeholder rather than the value — because a secret that can be re-displayed to any staff session is a secret that leaks through screenshots, screen shares and shoulder surfing. Decryption should happen only at the moment of use, server-side, never for display.

Encryption Doesn't Stand Alone

Encryption at rest is one layer of a posture, and it's worth seeing where it sits in the Singuard stack: transport encryption on the wire; 2FA and session revocation controlling who gets into portals at all; permission-scoped staff permissions ensuring the payments key never renders for a support agent; ID documents kept private and never on a public link; and a permanent audit trail recording every sensitive action. Fully managed hosting completes the picture — patching, backups and infrastructure hygiene are Singuard's operational responsibility, not a task list your two-person firm will get to eventually. The broader platform view is covered in trading platform security.

Questions to Ask Any Vendor (Including Us)

If you're evaluating platforms, secrets handling is a fast honesty test. Ask:

1. Are payment keys and integration secrets encrypted at rest, and with what? The answer should be a specific authenticated-encryption scheme — "AES-256-GCM" — not "our database is secure."
2. Can staff view a secret after it's saved? The right answer is no — masked after entry, decrypted only at use.
3. Who can change integrations, and is it logged? Look for role-scoping and an append-only audit log.
4. Who patches and backs up the infrastructure? "You do" is a real answer with a real cost; fully managed is the alternative.

A vendor that answers these crisply has thought about the problem. A vendor that hand-waves is storing your processor keys somewhere you wouldn't like.

"Secrets in plaintext are incidents on a timer. AES-256-GCM at rest is the minimum, not the achievement."

— Roman Onta, Executive Director, Broker CRM & UI/UX

Frequently Asked Questions