Security baselines, MFA and compliance evidence

Security baselines, MFA and compliance evidenceRequiring multi-factor authentication at sign-in, the security baselines an administrator can enforce for a whole estate, and how the product's controls map to SOC 2 and ISO/IEC 27001 — with no certification claimed. A security review of a business-intelligence tool asks the same questions every time: is multi-factor authentication enforced, can encryption and log retention be mandated centrally, and how do the controls line up with SOC 2 and ISO/IEC 27001? This page answers them for ATX AnalyticsTable as it ships, including what is off by default and what stays with your organisation.

Overview

A security review of a business-intelligence tool asks the same questions every time: is multi-factor authentication enforced, can encryption and log retention be mandated centrally, and how do the controls line up with SOC 2 and ISO/IEC 27001? This page answers them for ATX AnalyticsTable as it ships, including what is off by default and what stays with your organisation.

Signing in — single sign-on and multi-factor authentication

A server installation signs people in through the organisation's own identity provider: Microsoft Entra ID, any OpenID Connect provider (Okta, Ping, Keycloak, Auth0 and others) or any SAML 2.0 provider. The application never sees or stores a password. By default a session lasts at most 12 hours and ends after 60 minutes without a request, both adjustable; with OpenID Connect, roles are refreshed from the provider every five minutes; a person deactivated in the directory (SCIM, authoritative mode) is refused at once, and an administrator can block anyone immediately.
MULTI-FACTOR AUTHENTICATION is performed by the identity provider, never by the application — that is where the second factor, the device and the conditional-access rules belong. What the application adds is a check that it actually happened. With Require multi-factor authentication switched on (ANALYTICS_AUTH_REQUIRE_MFA=1, or the RequireMfa policy), every OpenID Connect or SAML sign-in must carry evidence of a second factor inside the signed token: for OpenID Connect, the amr claim contains mfa, or the acr value is one the administrator has listed as multi-factor (ANALYTICS_AUTH_MFA_ACR_VALUES); for SAML, Entra's authentication-methods claim contains multipleauthn, or the AuthnContextClassRef is one of those listed values.
Two weaker methods do not add up to a stronger one: a password plus a security question is still refused. A refused sign-in sees a page saying the server requires multi-factor authentication, and the audit trail records it as a denied sign-in with the code mfa_required and the methods the provider did report — so whoever owns the provider's policy can see which rule let a password-only sign-in through. It is OFF by default, because some providers never report the methods used and switching it on there would lock everybody out; try it with one account first.
It applies to interactive sign-in. Programs that call the API with an access token from Entra are governed by the conditional-access policy on their client application, because Entra access tokens do not reliably carry the methods used.

What counts as evidence of a second factor

OpenID Connect — The amr claim contains mfa (RFC 8176 — sent by Entra ID and Okta), or the acr value is listed in ANALYTICS_AUTH_MFA_ACR_VALUES — Several other amr values, such as pwd and kba, without mfa
SAML 2.0 — Entra's authnmethodsreferences claim contains multipleauthn, or the AuthnContextClassRef is listed in ANALYTICS_AUTH_MFA_ACR_VALUES — PasswordProtectedTransport, unless you list it yourself
Entra or OIDC bearer tokens (API calls) — Not checked by the application — Enforce MFA with conditional access on the client application
Off by default. Some providers, Google Workspace among them, never report the methods used, and requiring MFA there would lock everyone out. Switch it on for one test account first, then for everybody.

Security baselines an administrator can enforce

These are set fleet-wide like every other administrator policy — Group Policy and Intune through the ADMX templates shipped with the installer, a machine-wide policy.json or config.ini, or environment variables. The templates group them under Security.
Require multi-factor authentication for SSO sign-in — RequireMfa (DWORD 1) — An OpenID Connect or SAML sign-in without evidence of a second factor is refused and audited with the code mfa_required — Off
Require encryption of project databases — RequireDatabaseEncryption (DWORD 1) — New project databases are created AES-256-GCM encrypted, with the key in the vault; existing unencrypted ones keep opening and are converted from Settings — Off
Audit trail retention — AuditRetentionDays (whole days, 0 = forever) — Whole day files of the audit trail older than this are deleted, and the deletion is itself recorded — 400 days
Losing the operating-system keychain entry that holds a database key makes that encrypted database unrecoverable. Keep the vault key backed up as described under Installation and deployment before requiring encryption.

Certifications and compliance evidence

Stated plainly: ATX Institute does not hold a SOC 2 report or an ISO/IEC 27001 certificate, and this manual does not claim compliance with either. Those audits examine a company's own management system as well as its product. What the company provides instead is evidence about the product, for a security review or a questionnaire such as SIG, CAIQ or a bank's own ICT third-party assessment. The product repository holds a control matrix (docs/security/CONTROL_MATRIX.md) that maps each control described in this tab — sign-in and multi-factor authentication, roles, row- and column-level security, the audit trail and its retention, encryption at rest and in transit, masking, administrator policy, and the build and release pipeline — to the SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A, with its default and the tests that prove it.
A security assessment for each release, with the checks run on every build, their results and a register of findings, is available to organisations evaluating the product; it also cross-references DORA, the EBA guidelines on ICT and security risk and KNF Recommendation D. Because the application runs inside your own environment and sends no telemetry, the controls that a SOC 2 report covers for a hosted service — data-centre security, the vendor's access to production, the vendor's backups of your data — have no ATX system to apply to: your data never reaches one.
They are your organisation's controls, on your infrastructure, and the settings in this tab are how the application lets you meet them.

Control mapping at a glance

Identity and access — CC6.1–CC6.3 — 5.15–5.18, 8.5, 8.3 — SSO with Entra ID, OpenID Connect and SAML; MFA check; Viewer / Analyst / Admin roles; object grants; row- and column-level security; SCIM provisioning; immediate revocation; session limits
Logging and monitoring — CC7.2–CC7.3 — 8.15, 8.16 — Hash-chained audit trail with offline verification, SIEM forwarding over syslog/TLS, policy-set retention
Data protection — CC6.1, CC6.7, C1.1–C1.2 — 8.10, 8.11, 8.24 — Encrypted credential vault, optional database encryption, enforced TLS floor, PII masking and AI egress controls, no telemetry
Secure development and supply chain — CC6.8, CC7.1, CC8.1 — 8.8, 8.25–8.29 — Signed installers and container images, SBOMs, dependency and static-analysis gates on every change, secret scanning, pinned build actions, coordinated disclosure

What a certification would add

A SOC 2 Type II report or an ISO/IEC 27001 certificate would also examine ATX Institute as a company: its information security management system, personnel security, its own continuity and incident-response plans, and access to its build and signing infrastructure. Those are not product features, and this documentation does not stand in for them. In a questionnaire, answer the certification questions with no, and attach the control matrix and the security assessment as compensating evidence.

Glossary terms on this page

PII masking: definition

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.