Securing Your REDA Org

At go-live, one question outranks the rest: how do you lock this org down properly? Multi-factor authentication, My Domain, single sign-on, session and password policies — these are all Salesforce platform security features, not REDA features, so this article is a "secure your REDA org" checklist. It names each control, tells you where it lives, and routes the mechanics to Salesforce's documentation. The REDA-specific value is understanding that securing an org means doing two things at once: REDA's permission sets control authorization (which features), while the controls here handle authentication (who gets in). After reading, you'll have an ordered checklist and a clear sense of which parts are Salesforce's and which are REDA's.

Two layers: authentication and authorization

Securing a REDA org means configuring two separate layers, and it's worth keeping them distinct:

• Authorization — who can use which feature. REDA provides this through its permission sets (see Creating Users & Granting REDA Access).
• Authentication and session security — who gets in the front door, and how long they stay. MFA, My Domain, SSO, and session and password policies handle this. All are Salesforce Setup.

The go-live security checklist

Work these in order. Each row names the control, where it lives, and any REDA-specific note.

My Domain

My Domain gives your org a branded login URL and is the prerequisite for single sign-on and branded login pages. Deploy it first — the later steps assume it's in place. The mechanics are standard Salesforce; see the documentation below.

Multi-Factor Authentication (MFA)

Multi-factor authentication requires a second proof of identity — an authenticator app or security key — beyond the password. It is a Salesforce baseline requirement for direct logins, so it applies to every REDA user. Treat it as mandatory, not optional, and enable it in Salesforce Setup.

Single Sign-On (SSO)

Single sign-on lets users authenticate through your own identity provider (via SAML or OpenID Connect) rather than a separate Salesforce password. It's optional, and it's a Salesforce feature configured per your identity provider — REDA does not ship SSO configuration. If you enable it, My Domain must already be deployed.

Session & password policies

Session timeout, high-assurance sessions, IP login ranges, and password complexity and lockout are all standard Salesforce security settings. Set a session timeout appropriate to your risk (a two-hour timeout is common), require high-assurance sessions for sensitive admin actions, and set a password policy that matches your organization's standards. No REDA-specific values apply — these are pure Salesforce.

Don't forget the REDA access layer

Locking the front door doesn't finish the job — you still owe least-privilege on the authorization side. Review that each user holds only the REDA permission sets their persona needs (see Creating Users & Granting REDA Access). Two REDA-specific reminders:

• The REDA Admin Console is gated to REDA - Master Data - Admin only. A user without that set who opens it sees: "You do not have permission to perform this action in the REDA Admin Console." The generic access block elsewhere reads "Insufficient Access".
• Standard-object, report, and flow access are granted org-side through profiles — securing access means getting that baseline right too (see Profiles, Roles & Sharing in a REDA Org).

Worked example: securing a new org at go-live

Meridian Properties is going live on REDA. There's no numeric calculation here — the "worked example" is simply walking the checklist:

Where to go next

1. Creating Users & Granting REDA Access — create users and assign the REDA sets.
2. Profiles, Roles & Sharing in a REDA Org — the org-side baseline and record visibility.
3. Understanding REDA Permission Sets — the 31-set authorization model.
4. The REDA Admin Console — the Master-Data-Admin-only console.
5. Editions: OEM vs ISV — where the edition differences matter.

Frequently asked questions