🛡️ How We Protect Our Users — A Deep Dive into NiamonX Security Architecture

At NiamonX LTD, user protection isn’t just a feature — it’s the core of our engineering philosophy. Every decision we make, every line of code we write, is shaped by the principle that privacy and trust are non-negotiable. Below, we’ll take you behind the scenes and show — step by step — how our systems are built to keep your data safe, encrypted, and under your control.

1. Secure Authentication in Iceland — Zitadel IAM + AES-256-GCM

All authentication processes are handled through encrypted channels hosted in Reykjavík, Iceland, using Zitadel IAM — an enterprise-grade identity and access management platform.

Every sensitive field within Zitadel is encrypted using AES-256-GCM under the Zitadel Storage Encryption Layer, which ensures multi-level encryption and zero plaintext exposure. This covers:

• Passwords (bcrypt or Argon2id)

• Refresh and ID tokens

• Private keys for service accounts

• OAuth client secrets and credentials

We enforce strict password rotation policies and mandatory 2FA (Two-Factor Authentication).
In case of anomalies — such as cookie theft, sudden country change, or login pattern deviation — our system automatically triggers mitigation steps, session revocation, and account re-verification.

All authorization requests from other services are equally secured using TLS 1.3 encryption in transit (Data-in-Transit Encryption).

Backups are fully isolated, stored offline in air-gapped environments with independent AES encryption.
Employee access is restricted to authorized devices connected via company-signed VPNs — each machine authenticated by our internal public-key infrastructure.

🖼️ Suggested Illustration:

2. Encryption of User Data at Rest — Dual-Layer Protection

When users register or maintain their accounts, all personal information transmitted to us is protected under two complementary encryption layers:

1️⃣ Application-Level Encryption (ALE)

Each sensitive field is encrypted before it ever touches the database.
The flow looks like this:

AES-256-GCM → Envelope Encryption → KMS → HSM

Data is stored as binary ciphertext. During retrieval, the application decrypts it in real time using keys from a Hardware Security Module (HSM), orchestrated through our Key Management Service (KMS).

2️⃣ Transparent Data Encryption (TDE)

TDE ensures that even if an attacker accesses raw storage, they’ll see only unreadable ciphertext.
Example:
user_email → 0xA17F9D3B99A1C0E4B5...

External or analytical data is fully anonymized and decoupled from identifiable user information.
When an API key is generated, it’s hashed once using SHA-256 and never shown again.
Even our staff cannot retrieve it.

If data needs to be processed by an external provider at the user’s request, we anonymize and cryptographically sign it before transfer, guaranteeing integrity and minimal exposure.

Zero-log policy, your requests are stored locally in your browser.

🖼️ Suggested Illustration:

3. Human Factor Control — AI-Driven Staff Oversight

We recognize that even the most secure code can be compromised by human error or misuse.
That’s why we maintain strict internal access controls and continuous AI-based behavior analysis.

• Every employee’s actions are logged and monitored by local AI security models.

• Any abnormal or unauthorized operation triggers an automatic suspension pending review.

• Employees only see the minimal anonymized data required for their specific department.

• Cross-department access is impossible without cryptographically signed authorization.

In our HelpDesk systems, staff can’t view raw personal information — only masked or pseudonymized identifiers.
If any irregularity is detected in server operations (manual data access, process injection, or configuration changes), the affected node or cluster is immediately isolated for forensic inspection.

This layered oversight ensures zero-trust principles not only at the network level but within human workflows as well.

🖼️ Suggested Illustration:

4. Protection of Public and External Datasets — Field-Level Encryption & Confidential Computing

For datasets such as public breach archives or partner-supplied information, we implement heavy but secure field-level encryption (Application-Level).

Each PII (Personally Identifiable Information) field is encrypted in-app before writing to the database using AES-256-GCM.
Each record stores both ciphertext and its unique IV/nonce for decryption integrity.

Our key architecture is based on Envelope Encryption:

• Data Encryption Key (DEK) encrypts the actual data.

• Key Encryption Key (KEK) protects the DEK, stored securely in KMS/HSM.

• Master keys are never stored on the same servers as the data.

We enforce key rotation policies, version control, and segregation of duties — meaning even our developers cannot access raw keys or unencrypted PII in production.

For high-sensitivity tasks, we use Confidential Computing environments, enabling computation on encrypted data without exposure — a technology backed by secure enclaves (Intel SGX / AMD SEV).

If data arrives from external partners, it passes through a cryptographic minimization layer before reaching the client — bypassing all intermediate servers and ensuring end-to-end privacy.

Yes, this system is resource-intensive and costly.
But security and peace of mind are priceless.

🖼️ Suggested Illustration:

💡 Final Thoughts

Security at NiamonX isn’t an afterthought — it’s a foundational layer of our architecture.
From identity management in Iceland to encrypted storage, AI oversight, and confidential computing — every piece of our system is designed to defend your privacy even from us.

We don’t just protect your data.
We protect your trust.