Home · Synthesis · cl-authentication

Authentication architecture and multi-factor authentication

ISO 27001 PCI DSS RBI CSF RBI ITGRCA SEBI CSCRF CERT-In NIST CSF 2.0 RBI DLG/PA CIS Controls v8.1 NCIIPC NIS2 NIST 800-53

Primary statement

Authentication operates under: documented authentication policy with allowed methods and forbidden methods; multi-factor authentication (MFA) mandatory for all administrative, remote, customer-facing, and high-impact business access; strong session management with appropriate timeout and re-authentication for sensitive operations; modern protocols (SAML, OIDC) preferred over legacy (NTLM, basic auth); credentials managed under the broader IAM lifecycle with passwordless / phishing-resistant authentication as the strategic direction.

Audit-fatigue payoff

Demonstrating MFA enforcement across all access categories — administrative, remote, customer-facing — and producing a session-management policy documentation pack satisfies authentication requirements across all 12 contributing frameworks. The strictest specification is SEBI CSCRF PR.6 (MFA mandatory) + PR.13 (API authentication including signed requests) + ISO 27001 A.5.17 (authentication information handling). One MFA scan, one session policy, one API authentication architecture diagram — three artefacts against twelve framework expectations.

Strictness matrix

Scope

MFA scope: ALL administrative access, ALL remote access, ALL customer-facing authentication, ALL high-impact business roles (treasury, payment, SWIFT), ALL access to systems holding sensitive data. The scope is universal except for explicitly-justified machine-to-machine authentication using equivalently-strong mechanisms (mTLS, signed requests, OAuth client credentials with rotation). Ceiling source: sebi_cscrf:CSCRF.PR.6 Rationale: SEBI CSCRF PR.6 mandates MFA universally; no opt-outs except for documented machine-to-machine cases. This is the strictest scope specification across the cluster.

Threshold

API authentication threshold: every API call to a critical or customer-data-bearing system requires authenticated request — OAuth access token, signed request, or mTLS. Anonymous API access is permissible only for explicitly-public endpoints with documented rationale. Rate limiting + input validation + output encoding are additional thresholds for API security. Ceiling source: sebi_cscrf:CSCRF.PR.13 Rationale: SEBI CSCRF PR.13 is the strictest threshold articulator for API authentication. Other frameworks require "authentication" but do not specifically address API authentication; the API-specific threshold closes a common gap.

Method

Method: (1) documented authentication policy with allowed methods (SAML 2.0, OIDC, OAuth 2.0, mTLS, FIDO2/WebAuthn) and forbidden methods (basic auth in production, legacy NTLM v1, plain LDAP); (2) MFA via TOTP, push notification, FIDO2 hardware token, biometric + device — NOT SMS-only for high-value flows; (3) session management with timeout (typical 30 min for admin, 2 hour for general business); (4) credential rotation per the IAM lifecycle; (5) phishing-resistant authentication for high-value administrative roles (FIDO2 hardware preferred over TOTP). Ceiling source: sebi_cscrf:CSCRF.PR.1 Rationale: SEBI CSCRF PR.1 with the August 2025 zero-trust expectations + the PR.6 MFA specification combine to the strictest method articulation. The phishing-resistance requirement for high-value roles is the leading edge of 2026 authentication best practice.

Frequency

Credential rotation: per the IAM lifecycle (typical: passwords 90 days for non-MFA accounts, eliminated for MFA-protected accounts; service account credentials annual; API keys quarterly or on event). Session timeout: per session policy. MFA enrollment: at account creation. Authentication audit: continuous via SIEM + monthly review. Ceiling source: iso27001:A.5.17 Rationale: ISO 27001 A.5.17 addresses authentication information handling including the lifecycle. The frequency model is consistent across frameworks but A.5.17 provides the most-comprehensive specification.

Evidence

Required evidence: (1) authentication policy with allowed/forbidden methods; (2) MFA enforcement report across all in-scope access categories — administrative, remote, customer-facing, high-impact business; (3) session management policy + sample enforcement evidence; (4) SSO inventory; (5) authentication audit log sample showing failed authentication monitoring; (6) API authentication architecture diagram showing OAuth / mTLS / signed-request flows. Ceiling source: sebi_cscrf:CSCRF.PR.6 Rationale: SEBI CSCRF PR.6 enforcement-report evidence is the most enumerative. The MFA-enforcement scan across all categories is the audit-defensible evidence ceiling.

Auditor test pattern

Step 1: Inspect the authentication policy; verify forbidden methods are explicitly listed and rejected. Step 2: Sample 3 administrative access paths and verify MFA enforcement (try to access without MFA — should fail). Step 3: Sample 3 customer-facing authentication flows and verify MFA / risk-based step-up. Step 4: Inspect API authentication for 2 critical APIs; verify authenticated requests + rate limiting. Step 5: For high-value administrative roles, verify phishing-resistant authentication (FIDO2 hardware token preferred over TOTP). Step 6: Inspect session management policy and sample enforcement (verify session timeout actually works).

Common findings

Common 2024–26 findings: (1) MFA bypassable via legacy "service account" identities still using passwords; (2) SMS-based MFA for high-value flows (vulnerable to SIM swap); (3) Session timeout policy exists but is not enforced in legacy applications; (4) APIs accept anonymous requests where authentication was assumed; (5) Phishing-resistant authentication not deployed for high-value admin roles — relies on TOTP which is phishable; (6) Forbidden methods (basic auth, NTLM v1) still enabled in legacy systems.