Identification and Authentication (Non-Organizational Users) | Use of Defined Profiles

To meet Identification and Authentication (Non-Organizational Users) | Use of Defined Profiles, you must define identity-management profiles for non-organizational users (external users) and make your IAM implementation conform to those profiles across onboarding, authentication, authorization, and lifecycle changes. Auditors will look for documented profiles plus proof your configurations and access decisions match them. ¹

Key takeaways:

• Define “profiles” that standardize how external identities are created, authenticated, and governed, then enforce them in IAM. ¹
• Treat profiles as configuration baselines: claims, assurance levels, MFA rules, session limits, and lifecycle events must align to the profile. ¹
• Keep evidence that profiles exist, are approved, and are actually enforced through settings, logs, and periodic conformance checks. ¹

This enhancement is easy to misunderstand because the regulatory text is short, but the operational expectation is not. “Conform to organization-defined profiles for identity management” means you must decide, document, and enforce standardized identity patterns for non-organizational users: people who authenticate to your system but are not your workforce. In a FedRAMP context, that often includes customer users, partner users, contractor accounts not managed as workforce identities, and other external users who access your cloud service. ¹

For a CCO or GRC lead, the fastest path is to treat “profiles” as enforceable IAM baselines. A profile defines what an external identity is allowed to be, how it proves who it is (identity proofing assumptions, authentication strength), what attributes and claims it must carry, how it is authorized, and how it is monitored and terminated. Then you harden systems so external users cannot bypass that profile through ad hoc exceptions, local accounts, or misconfigured identity providers.

The rest of this page gives requirement-level guidance you can hand to IAM engineering and your control owners, plus the evidence package you should retain for assessment. ¹

Regulatory text

Requirement (excerpt): “Conform to organization-defined profiles for identity management.” ¹

What the operator must do:

1. Define identity-management profiles for non-organizational users that specify allowed identity sources, required attributes, authentication methods, and lifecycle rules.
2. Configure your IAM and application integrations to match those profiles and prevent access flows that do not conform.
3. Prove conformance with configuration evidence, joiner/mover/leaver workflows, and logs showing external accounts follow the profile rules. ¹

Plain-English interpretation

“Defined profiles” means you stop treating external identities as one-offs. You publish a small set of approved patterns (profiles) and require that every non-organizational user account fits one of them. A profile is not a diagram in a slide deck; it is a binding standard that drives how you implement SSO, MFA, claims/attributes, session controls, account recovery, and offboarding for external users. ¹

If an external user cannot fit a profile, you either:

• create a new profile with explicit security rules and approval, or
• deny the access model.

That is the governance intent behind “conform.” ¹

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies implementing NIST SP 800-53 controls (including FedRAMP-authorized systems where applicable). ¹

Operational context (non-organizational users):

• Customer users authenticating to your SaaS
• Partner users (resellers, integration partners)
• Third-party support personnel granted portal access
• External developers with API access via a developer portal
• Contractors treated as “external” rather than workforce identities

If your system accepts external identities through SAML/OIDC federation, social login, local accounts, API keys tied to an external developer, or delegated administration by a customer, this requirement is in play. ¹

What you actually need to do (step-by-step)

1) Define your non-organizational user profile set

Create a short list of profiles that covers your real access patterns. Common examples:

• Federated partner user profile (SAML/OIDC from partner IdP)
• Customer SSO profile (enterprise customer federation)
• Direct customer account profile (local account + MFA)
• External developer/API profile (OIDC + scoped tokens, or API key lifecycle rules)

Each profile document should specify:

• Identity source: which IdPs are allowed; whether local accounts are permitted
• Assurance requirements: MFA requirement, allowed authenticators, re-auth rules
• Minimum attributes/claims: email format rules, immutable subject identifier, tenant ID, role/entitlement attributes
• Provisioning method: SCIM/JIT/manual; approval points; who can approve
• Authorization model: RBAC/ABAC mapping rules; least-privilege defaults; admin role constraints
• Session controls: max session age, idle timeout expectations, token lifetime approach
• Account recovery: how resets work; high-risk recovery controls
• Lifecycle: deprovision triggers; inactivity handling; periodic access review expectations
• Logging/monitoring: events required (auth success/failure, MFA events, privilege changes)

Keep the profile set “small but complete.” Too many profiles create exception sprawl and make conformance hard to prove. ¹

2) Map every external access path to exactly one profile

Build an inventory:

• Applications and APIs that accept non-organizational users
• Authentication methods supported by each (SAML, OIDC, password, magic link, etc.)
• Admin consoles and support portals that may have separate auth stacks
• Break-glass or emergency external access patterns

Then, for each access path, record the assigned profile and the enforcement point (IdP policy, application policy, API gateway policy). If you find “shadow” paths (local accounts left enabled, legacy endpoints, shared accounts), treat them as nonconformities to remediate. ¹

3) Enforce profiles through IAM configuration baselines

Translate each profile into enforceable settings. Examples of what auditors expect to see tied back to the profile:

• IdP conditional access policies for MFA and risky sign-in handling
• SAML/OIDC configuration standards (signed assertions, required claims, audience restrictions)
• Just-in-time provisioning constraints (allowed domains, tenant binding, role defaults)
• Role assignment controls (no external user can self-assign admin roles)
• API token issuance rules and scope constraints for external developers
• Disallow “local login” if the profile requires federation

A practical pattern is to maintain an IAM profile-to-policy matrix that shows: Profile → Control rule → Where enforced → Owner. That becomes your conformance backbone for assessment. ¹

4) Build exception handling that does not destroy conformance

Exceptions will happen (partners without MFA, customers needing a transitional model). Your exception process should:

• Require documented risk acceptance with compensating controls
• Time-bound the exception
• Track exceptions by profile and by tenant/customer
• Require periodic review and closure

The goal is to keep “defined profiles” meaningful. If exceptions become normal operations, your program no longer conforms. ¹

5) Validate conformance continuously

Add at least these checks:

• Configuration conformance reviews: verify IAM policies still match profile requirements after changes
• Sampling: pick external users in each profile and confirm attributes, MFA status, role grants, and last-login behavior match the profile
• Change control hooks: profile changes require security review; high-impact IAM changes require mapped profile impact analysis

If you use Daydream to manage third-party and external access governance, treat these profiles as controlled requirements with mapped evidence requests (policy docs, IdP screenshots/exports, log samples) and track exceptions as time-bound issues tied to the affected profile. That keeps assessment prep and ongoing control monitoring in one place.

Required evidence and artifacts to retain

Keep an “IA-8(4) evidence packet” with:

• Identity management profile documents (versioned, approved) ¹
• Profile-to-system mapping inventory (apps/APIs/portals → profile assignment) ¹
• IAM configuration exports or screenshots showing enforcement (conditional access, SSO settings, claim mappings, JIT/SCIM settings) ¹
• Samples of external account records (redacted) showing required attributes and tenant binding ¹
• Access lifecycle records: provisioning approvals, deprovision tickets, identity proofing steps if applicable ¹
• Logging evidence: authentication events, admin role changes, token issuance logs for external developer profiles ¹
• Exception register: rationale, compensating controls, approvals, and closure evidence ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me your defined identity profiles for non-organizational users. Who approved them?” ¹
• “Pick a customer tenant. Which profile applies, and where is it enforced?” ¹
• “How do you prevent external users from authenticating through a weaker method?” ¹
• “How do you ensure required claims/attributes are present and correct?” ¹
• “How do you handle partners who cannot meet your MFA requirement?” ¹
• “Prove deprovisioning works for external identities.” ¹

Hangups that slow assessments:

• Profiles exist, but engineering cannot show enforcement points.
• Multiple auth stacks exist (main app vs admin portal) with inconsistent policies.
• JIT provisioning creates accounts without stable identifiers or tenant binding. ¹

Frequent implementation mistakes (and how to avoid them)

1. Writing profiles as “guidance” instead of standards.
   Fix: include explicit “MUST” requirements and map each one to an enforceable control or configuration. ¹

2. Allowing local accounts “just in case.”
   Fix: disable local login where profiles require federation; if you need a break-glass path, define a separate tightly controlled profile with strong approvals and monitoring. ¹

3. No consistent external identity identifier.
   Fix: require an immutable subject identifier and tenant-scoped identity mapping in the profile; validate it in your auth pipeline. ¹

4. Exception sprawl.
   Fix: time-bound exceptions, require compensating controls, and track them as audit-visible items. ¹

5. Profiles that ignore API access.
   Fix: include token issuance, scopes, rotation, and revocation rules for external developer/API profiles. ¹

Risk implications (why assessors care)

If you do not enforce defined profiles, external identity becomes a weak link: inconsistent MFA, inconsistent claims, and inconsistent offboarding. That increases the chance of unauthorized access, cross-tenant exposure, and persistence of stale accounts. Profiles reduce that risk by forcing repeatable identity decisions and making misconfigurations detectable. ¹

A practical 30/60/90-day execution plan

Day 0–30: Define and inventory

• Name the control owner for non-organizational IAM profiles and enforcement. ¹
• Draft your initial profile set (keep it small) and get formal approval. ¹
• Inventory all external authentication entry points (app, admin, support, APIs). ¹
• Create the profile-to-system mapping and identify nonconforming paths. ¹

Day 31–60: Enforce and close gaps

• Implement IAM policies per profile (MFA rules, federation constraints, claim requirements). ¹
• Remove or restrict legacy/local auth paths that violate profiles. ¹
• Stand up an exception workflow with approvals and time bounds. ¹
• Start collecting evidence artifacts continuously (configuration exports, sample logs). ¹

Day 61–90: Prove conformance and operationalize

• Run conformance sampling across each profile; document results and remediation. ¹
• Add profile impact review to change management for IAM and auth-related releases. ¹
• Establish a recurring review cadence for profiles, exceptions, and tenant-specific deviations. ¹
• Package the assessment-ready evidence set and keep it current in your GRC system (Daydream works well if you want profile-mapped evidence requests and exception tracking in one workflow). ¹

Frequently Asked Questions

What counts as a “defined profile” for identity management?

A defined profile is a documented, approved standard for a category of external users that specifies identity source, required authentication strength, required claims/attributes, lifecycle rules, and enforcement points. It must be actionable and enforceable, not aspirational. ¹

Are customers who log into our SaaS “non-organizational users”?

Yes, if they are not part of your workforce identity population and they authenticate to your system. Treat each customer access model as a profile, especially if you support both SSO and local login. ¹

If we support both SAML SSO and username/password, do we need two profiles?

Usually yes, because the identity source, assurance method, recovery, and enforcement differ. If you allow both for the same population, document the rule for when each is permitted and enforce it through configuration. ¹

How do we prove “conformance” during an assessment?

Show approved profile documents, then demonstrate the technical enforcement in your IdP/app settings and provide samples of external accounts and logs that match profile requirements. A profile-to-system mapping matrix makes this easy to walk through. ¹

What if a third party cannot meet our MFA requirement?

Treat it as an exception to the profile with documented compensating controls, explicit approval, and a plan to close the gap. Keep the exception time-bound and easy to retrieve during audit. ¹

Do APIs count under this requirement, or only interactive users?

APIs count if non-organizational users obtain credentials or tokens to access them. Define an external developer/API profile with token issuance, scope constraints, and revocation rules, then enforce it at the IdP and API gateway where possible. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5