generated: '2026-09-06' method: probed source: >- https://sso.securian.com/.well-known/openid-configuration ; https://sso.securian.com/.well-known/oauth-authorization-server ; https://www.securian.com/employers/flexible-administration/strategic-partnerships/securian-platform-connect.html note: >- Two classes of evidence are kept apart on purpose. The OAuth/OIDC entries are read from machine-readable documents Securian serves and are directly verifiable. The insurance domain-standard entries are FIRST-PARTY PROSE CLAIMS on securian.com — Securian says it aligns its API connections to LIMRA's LDEx standards — and there is no published contract to check them against, so each carries contract_evidence: none. Nothing here is inferred from a spec we do not have. entries: - id: oauth2 label: OAuth 2.0 (RFC 6749) conforms: true evidence: https://sso.securian.com/.well-known/oauth-authorization-server verification: machine-readable-document - id: oauth2-authorization-server-metadata label: OAuth 2.0 Authorization Server Metadata (RFC 8414) conforms: true evidence: https://sso.securian.com/.well-known/oauth-authorization-server verification: machine-readable-document - id: oidc label: OpenID Connect Core 1.0 + Discovery 1.0 conforms: true evidence: https://sso.securian.com/.well-known/openid-configuration verification: machine-readable-document - id: oidc-rp-initiated-logout label: OpenID Connect RP-Initiated / Back-Channel / Front-Channel Logout conforms: true evidence: >- https://sso.securian.com/.well-known/openid-configuration — backchannel_logout_supported: true, frontchannel_logout_supported: true, end_session_endpoint present verification: machine-readable-document - id: pkce label: PKCE (RFC 7636) conforms: true evidence: 'code_challenge_methods_supported: [S256] in the discovery document' verification: machine-readable-document - id: rfc9126-par label: OAuth 2.0 Pushed Authorization Requests (RFC 9126) conforms: true evidence: 'pushed_authorization_request_endpoint: https://sso.securian.com/as/par.oauth2' verification: machine-readable-document - id: rfc9449-dpop label: OAuth 2.0 Demonstrating Proof of Possession (RFC 9449) conforms: true evidence: dpop_signing_alg_values_supported advertised in the discovery document verification: machine-readable-document - id: rfc8705-mtls label: OAuth 2.0 Mutual-TLS Client Authentication (RFC 8705) conforms: partial evidence: >- tls_client_auth is offered in token_endpoint_auth_methods_supported, but tls_client_certificate_bound_access_tokens is absent — mTLS client authentication without certificate-bound access tokens. verification: machine-readable-document - id: rfc8628-device-grant label: OAuth 2.0 Device Authorization Grant (RFC 8628) conforms: true evidence: 'device_authorization_endpoint: https://sso.securian.com/as/device_authz.oauth2' verification: machine-readable-document - id: rfc8693-token-exchange label: OAuth 2.0 Token Exchange (RFC 8693) conforms: true evidence: 'urn:ietf:params:oauth:grant-type:token-exchange in grant_types_supported' verification: machine-readable-document - id: rfc7662-introspection label: OAuth 2.0 Token Introspection (RFC 7662) conforms: true evidence: 'introspection_endpoint: https://sso.securian.com/as/introspect.oauth2' verification: machine-readable-document - id: rfc7009-revocation label: OAuth 2.0 Token Revocation (RFC 7009) conforms: true evidence: 'revocation_endpoint: https://sso.securian.com/as/revoke_token.oauth2' verification: machine-readable-document - id: rfc7591-dynamic-client-registration label: OAuth 2.0 Dynamic Client Registration (RFC 7591) conforms: true evidence: 'registration_endpoint: https://sso.securian.com/as/clients.oauth2' verification: machine-readable-document - id: ciba label: OpenID Connect Client-Initiated Backchannel Authentication (CIBA) conforms: true evidence: 'urn:openid:params:grant-type:ciba in grant_types_supported' verification: machine-readable-document - id: rfc9207-iss-parameter label: OAuth 2.0 Authorization Server Issuer Identification (RFC 9207) conforms: false evidence: 'authorization_response_iss_parameter_supported: false' verification: machine-readable-document - id: fapi label: FAPI 1.0 / FAPI 2.0 conforms: false evidence: >- No FAPI profile is advertised in the authorization-server metadata and Securian makes no FAPI claim. Recorded as an honest false, not a penalty — Securian is a US life and group-benefits carrier, not an open-banking data holder. verification: machine-readable-document domain_standard: id: ldex label: LIMRA Data Exchange (LDEx) Standards body: LIMRA body_url: https://www.limra.com/en/solutions-and-services/data-exchange-standards/ldex-overview/ declared_in_contract: false claimed_by_provider: true contract_evidence: none evidence: https://www.securian.com/employers/flexible-administration/strategic-partnerships/securian-platform-connect.html quote: >- "Securian Financial is prioritizing API connections that align with LDEx, LIMRA's standardized data exchange format." profiles: - id: ldex-eois label: LDEx Evidence of Insurability Status (EOIS) conforms: claimed contract_evidence: none evidence: >- Securian Platform Connect page names the EOIS standard and describes "EOI decisions reflected via API". - id: ldex-bem label: LDEx Benefits Enrollment Management (BEM) conforms: claimed contract_evidence: none evidence: >- Securian Platform Connect page names BEM as supporting "standardized enrollment data exchange between benefits administration platforms". LDEx BEM 2.0 defines REST API transmission, which is consistent with the auth-gated AWS API Gateway hosts (api.connect.securian.com, api.lifebenefits.com) probed for this record. note: >- LDEx is not currently in the insurance regime's standards[] list in scoring.yml, which carries the ACORD family (acord, acord-al3, acord-xml, ngds, grlc, cieca-bms, csio, market-reform-contract). LDEx is the US group-benefits/workplace-benefits data-exchange standard and is the one this provider actually names; worth adding upstream. gaps: - >- No published compliance program, certification list (SOC 2 / ISO 27001 / PCI / HIPAA), or trust center. https://www.securian.com/about-us/sustainability/inspiring-trust/cybersecurity-and-data-privacy.html (HTTP 200) describes practices in prose and names no framework, so no Compliance pointer is emitted for this record. - >- The LDEx alignment cannot be verified without a contract. If Securian published the OpenAPI behind Securian Platform Connect, domain_standard_conformance would move from a prose claim to a checkable one.