Security at NamoID
NamoID protects customer authentication and scoped authorization for APIs and MCP clients. This page describes the controls implemented today, our India and DPDP-readiness posture, completed assessments, known assurance boundaries, and how to report a vulnerability.
How we protect your data
- All public service traffic is served over TLS. Tokens are RS256-signed and verifiable via our published JWKS — the private signing key is not published and is held by the identity service.
- PKCE S256 is mandatory for authorization-code requests. There is no implicit flow and no password grant.
- Refresh tokens rotate on every use; a replayed refresh token revokes the entire token chain and raises a security event.
- Connected-provider tokens are encrypted at rest with AES-256-GCM, under a rotatable key. They never appear in logs.
- Security-sensitive lifecycle actions create append-only audit events with tenant, project, and environment context where applicable.
- Tenant, project, and environment identifiers are carried through the identity data model and authorization checks.
- Auth and OTP endpoints are rate-limited (Redis-backed) to defend against credential stuffing and OTP-flood abuse.
- Dependencies follow a 7-day publish-age cool-off to blunt supply-chain attacks; CI runs secret-scanning, dependency/CVE audit, and static analysis.
Privacy & data protection (India / DPDP)
NamoID is designed to support DPDP-readiness work. Primary production infrastructure is hosted in AWS Mumbai (ap-south-1); optional providers and subprocessors may process data elsewhere as described in the Privacy Policy.
- The Aadhaar offline-XML verification adapter validates signed input and does not write a verification record in the current flow. It is not a claim of UIDAI approval.
- Hosted account workflows support profile correction, export of audit and processing history, and account soft deletion with a tombstone event. Complete cross-domain export and automated cascading erasure are not claimed.
- Provider linking creates an audit event with actor context and timestamp. MCP resource grants separately persist the resource and approved scopes.
Sub-processors
Primary identity-service subprocessors that handle customer identity data run on Amazon Web Services in the Mumbai (ap-south-1) region. Marketing and business-service transfers are disclosed separately in the Privacy Policy.
| Sub-processor | Purpose | Region |
|---|---|---|
| Amazon Web Services | Compute, database, and cache (EC2, PostgreSQL, Redis) | ap-south-1 |
| Amazon SES | Transactional email (OTP, verification, password reset) | ap-south-1 |
| Amazon End User Messaging | SMS OTP delivery | ap-south-1 |
Assessments & compliance
Our control program follows the direction of India’s DPDP Act, GDPR privacy principles, ISO 27001 information-security management, and the SOC 2 security, availability, and confidentiality criteria. Readiness and alignment do not mean certification or independent assurance. We publish only assessments and certifications that have actually been completed.
We run internal security assessments by the PolyMindsLabs security team (the team behind NamoID) against an OAuth/OIDC-specific test plan, and publish a summary of each. To be clear about provenance: these are first-party assessments.
We have published a CSA STAR Level 1 self-assessment (CAIQ v4.1.0) to the Cloud Security Alliance registry — a public, standards-based account of our security and privacy controls (Level 1 is a self-assessment, not a third-party audit). View our CSA STAR listing →
NamoID has not yet completed an independent third-party penetration test or a SOC 2 / ISO 27001 certification. We pursue independent certification as customer requirements call for it. A detailed threat model and full assessment results are available under NDA.
Live service status and uptime history: status.namoid.in.
Reporting a vulnerability
Email security@namoid.in (falls back to hello@namoid.in). We acknowledge within 48 hours and triage within 5 business days.
Include a clear description, reproduction steps, impact assessment, and (optional) a suggested fix.
Fix-time targets
| Severity | Target fix time |
|---|---|
| Critical (auth bypass, RCE, token leak) | 7 days |
| High (privilege escalation, PII exposure) | 30 days |
| Medium (CSRF, info disclosure) | 60 days |
| Low / informational | Best effort |
Safe harbor
If you act in good faith (no data exfiltration beyond proof-of-concept, no service disruption, no targeting of other customers' accounts, and you give us time to fix before disclosing), we won't pursue legal action.
- Testing your own NamoID test-mode accounts is fine.
- Reasonable rate-limit probing is fine.
Not covered
- Phishing or social engineering of NamoID staff or customers.
- Attacks against other customers' production environments or their end-users.
- Persistent denial-of-service.
- Exfiltrating more PII than the minimum needed to demonstrate the issue.
- Public disclosure before a fix ships or 90 days have passed since acknowledgement.
Out of scope
- Missing security headers on marketing pages with no user state.
- Self-XSS or clickjacking without a working account-takeover PoC.
- Automated-scanner output with no proof of exploitability.
- Vulnerabilities in dependencies that don't affect our usage.
- Email spoofing on domains we don't own.
Hall of fame
No reports acknowledged publicly yet. Be the first.