Greenhouse Recruiting holds CVs, interview feedback, offer details and contact data for every candidate, and a growing share of applicants are not who they claim to be, so both the people who sign in and the people who apply need checking. The controls that matter sit on the customer side: SSO and two-step verification, the Basic, Job Admin and Site Admin permission levels, developer permissions, Harvest API credentials and OAuth connections, support access, the audit log, data retention rules and Real Talent identity verification. This guide explains how to configure each of them with menu paths and options from Greenhouse's own support site. It is written for Greenhouse Site Admins, recruiting operations and HR systems owners, and security teams who review recruiting SaaS. For the wider hiring fraud picture, see the Hiring Fraud and Candidate Identity Verification Guide.
This is an independent guide from NHI Mgmt Group, based on Greenhouse's public documentation as of November 2026. It is not sponsored or reviewed by Greenhouse. Product features change, so confirm settings against Greenhouse's current documentation.
Key takeaways
- Hard-enable SSO after a soft-enabled pilot. Soft-enabled SSO keeps passwords as an option; hard-enabled SSO deletes every password and makes the identity provider the only door, so bring external recruiters into the identity provider first.
- Keep developer permissions rare. "Manage ALL organization's API Credentials" reaches candidate, job and interview data through Harvest, and any user level can hold it, so grant it to named integration owners only.
- Move integrations to Harvest v3 under an Integration System User. Harvest v1/v2 keys are being retired; v3 OAuth credentials created by a person stop working when that person leaves.
- Export the audit log. The audit log (Pro tier) keeps 30 days of data and raises no alarms, so pull it through the API or Business Intelligence Connector into your SIEM.
- Verify candidates and expire their data. Use Real Talent identity verification and Fraud Detection (Plus and Pro) at the right stages, and data retention rules to anonymise candidates once you no longer need their data.
How identity and access work in Greenhouse Recruiting
Every Greenhouse user signs in with an email address (or Employee ID on Pro) and then sees only what their permission level allows. Greenhouse describes its model as a tiered system intended to limit bias from users seeing too much about candidates and jobs, which also makes it a least-privilege model by design.
| Sign-in option | How it works (Greenhouse docs) | Recommended use (NHI Mgmt Group recommendation) |
|---|---|---|
| Email and password | Email verification code is required for all non-SSO users and cannot be turned off; optional SMS codes once an admin enables them | Only until SSO is hard-enabled |
| SSO, soft-enabled | Users choose SSO or their existing password | Pilot and transition period |
| SSO, hard-enabled | SSO only; all passwords deleted and not recoverable; two-step verification no longer required because the identity provider handles MFA | Target state for all staff and agency users |
SSO configuration
The path is Configure > Dev Center > Single sign-on, and the user needs the developer permission Manage and configure SSO. Greenhouse auto-generates the Assertion (ACS) URL. Key settings:
- Entity ID: for most identity providers set it to
greenhouse.iowithouthttps://; check the Greenhouse article for your provider. - NameID format:
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. Only email works as the NameID; persistent and transient formats do not. - Certificate fingerprint: use SHA-256, which Greenhouse recommends.
- Metadata: upload the identity provider's metadata XML to fill the fields, or enter the SSO URL, optional logout URL and fingerprint manually.
- Rollout: click Begin Testing (status "In testing"), then Finalize Configuration by typing "Configure". Removing SSO later needs a Greenhouse Technical Support ticket and a password reset for every user.
Before hard-enabling, list every agency recruiter, contractor and hiring partner who signs in with a password. Greenhouse warns that they lose access unless they are added to your identity provider. See the SAML Security Guide.
Two-step verification for password users: SMS is enabled at Configure > Permissions > General Settings > Users, and each user opts in at Account Settings. Codes otherwise go to the primary email, and a Site Admin can change a user's primary email from their profile, so treat that change as a sensitive action and confirm the request out of band (our recommendation). SMS is not offered for organisations in some countries, including Singapore and the United Arab Emirates; there, rely on email codes until SSO is hard-enabled.
Admin roles and privileged access
| Level or permission | Scope (Greenhouse docs) | Least-privilege guidance (ours) |
|---|---|---|
| Site Admin | Organisation-wide configuration; grants developer permissions; sets retention rules; reviews the Change Log; can grant support access to all accounts | Two or three named recruiting operations or HR systems owners, reviewed quarterly |
| Job Admin | Assigned jobs only, with a Job Admin level: Standard, Private (preconfigured, customisable on Advanced and Pro) or Custom | Use Standard by default; Private only for confidential roles; Custom for specific needs |
| Basic | Entry level; no user-specific permissions available | Default for interviewers and hiring team members |
| User-specific permissions | Extra abilities on top of Job Admin or Site Admin level | Grant per person with a reason, review quarterly |
| Developer permissions | Assignable at any level by a Site Admin who can edit advanced permissions | Named integration owners only |
Developer permissions
Developer permissions are set at Configure > Users > [user] > Permissions. Because any user level can hold them, a Basic user with developer permissions can have more data reach than a Site Admin's day-to-day work suggests. Review these first:
| Developer permission | What it allows | Who should hold it (ours) |
|---|---|---|
| Manage ALL organization's API Credentials | Job Board and Harvest API credentials: jobs, candidates, interviews and other data | One or two integration owners |
| Manage Job Board related API Credentials | Job Board API for careers pages | Careers site developers |
| Manage and configure webhooks | Webhooks that send event data to external endpoints | Integration owners; review endpoints quarterly |
| Manage and configure SSO | SSO configuration | Identity team |
| Manage and configure BIC (Plus and Pro) | Business Intelligence Connector data export | Data or analytics owner |
| Can configure email settings | Email services and related settings | Recruiting operations lead |
Greenhouse support access
Any user can grant Greenhouse Technical Support temporary access to their own account from Account Settings > Greenhouse Support Access. Site Admins can widen this to All user accounts at my organization, which lets support sign in as any user and perform admin operations such as editing integrations and session timeouts. Access expires at the end of the chosen duration, can be revoked early, and every Site Admin is emailed when organisation-wide access is granted. Audit it in Configure > Change Log by searching for "Temporary Access Granted", "Temporary Access Revoked" and "Phantom User Login". Our recommendation: grant the narrowest scope and the shortest duration that fits the support case. See SaaS Admin Account Protection.
Integrations, API tokens and service accounts
Recruiting integrations (assessment tools, background checks, HR systems, sourcing tools) are non-human identities with standing access to candidate data. Greenhouse offers three patterns, all available on Core, Plus and Pro:
| Credential | How it works (Greenhouse docs) | Controls |
|---|---|---|
| Harvest v1/v2 API key | Shown once at creation; endpoint permissions set with Manage permissions; access being retired by an organisation-specific cutoff date | Migrate to Harvest v3; confirm your cutoff date with Greenhouse |
| Harvest v3 (OAuth) credentials | Client key and client secret; secret shown once; cannot be regenerated or transferred; break if the creating user is deactivated | Create under an Integration System User; store the secret in a vault |
| Harvest v3 partner connection, service account | Organisation-level service user with no username or password; only a Site Admin can choose it | Use where the partner supports it; one connection per partner |
| Harvest v3 partner connection, user-tied | Authorisation tied to the person who connected it; actions appear as that user | Avoid for long-running integrations |
Creating and reviewing credentials
- Create at Configure > Dev Center > API Credential Management > Create new API credentials. Choose the API type, the partner (or "custom"), and a description naming the system and owner.
- Set endpoint permissions with Manage permissions (v1/v2) or View and store credentials (v3). Greenhouse notes that granting an endpoint works like giving a user access to that data, so grant only what the partner documents as required.
- Store the secret in a secrets manager before confirming "I have stored the client credentials". It cannot be shown again.
- Use an Integration System User as the creator for v3 credentials so a leaver does not break the integration or leave credentials tied to a disabled person.
- Review connections at Configure > Dev Center > Connected Integrations, which shows each integration, who connected it and when. Disconnect takes effect immediately.
- Replace rather than rotate v3 credentials: since secrets cannot be regenerated, create new credentials, move the integration, then remove the old ones. Our recommendation is at least yearly and on any suspected exposure.
See the SaaS API Token Security Guide, the SaaS and OAuth App Governance Guide and, if a key leaks, the Work SaaS API tokens response guide.
Logging and detection
Greenhouse has two log sources:
- Change Log (Configure > Change Log): reviewed by Site Admins; includes logins and support access events.
- Audit log (Pro tier): records important events with metadata, including API key usage. Most events create several entries linked by
request_id, which shows before and after values. Events on sensitive, long-text or custom fields do not include before and after values. Data is kept for 30 days from when the audit log is enabled, and there are no built-in alarms.
Collect audit data through the Audit log API (use paging=true and after_time set to the last pull for incremental collection) or through the Business Intelligence Connector (Redshift queries or S3 copies, at least every 30 days). Our recommendation is an API pull at least hourly into your SIEM.
| Signal | Source | What to look for |
|---|---|---|
| API key usage | Audit log | Use from a credential with no owner, at unusual volume, or after its system was retired |
| Permission and developer permission changes | Audit log | New Site Admins or "Manage ALL organization's API Credentials" grants outside change records |
| Support access | Change Log | "Temporary Access Granted" for all accounts; "Phantom User Login" with no open support case |
| Candidate data events | Audit log (check Greenhouse's event glossary for coverage) | One user acting on unusually many candidate records |
| SSO and login | Change Log and identity provider logs | Password sign-ins while SSO is soft-enabled; primary email changes before a login |
See the SaaS Audit Log Retention and Licensing Guide.
Metrics that show it is working:
- Share of users signing in through SSO (target 100% after hard-enable).
- Number of Site Admins (target three or fewer) and holders of each developer permission.
- Integrations on Harvest v3 under an Integration System User or service account (target 100% before your cutoff).
- Credentials with a named owner and a review in the last quarter.
- Hours of lag between audit events and SIEM ingestion (target under one).
- Candidates past retention not yet anonymised (target zero).
Hardening baseline
A phased rollout. Hard-enabling SSO deletes passwords and cannot be undone without a support ticket, and swapping credentials can interrupt integrations, so schedule both.
- Inventory: export users by level, list developer permission holders, credentials, connected integrations and webhook endpoints, and every password-only user.
- Reduce privilege: trim Site Admins, review Job Admin levels and user-specific permissions, and remove unneeded developer permissions.
- Configure SSO, test, soft-enable for a pilot, add agency users to the identity provider, then hard-enable.
- Enable SMS two-step for any password users who remain during the transition.
- Migrate integrations to Harvest v3 under an Integration System User or partner service account, then remove v1/v2 keys.
- Connect the audit log (Pro) to the SIEM and set alerts for permission changes and support access.
- Set data retention rules for hired and rejected candidates with legal counsel, test with notifications only, then turn on automatic anonymisation.
- Turn on Real Talent controls (Plus and Pro) after reviewing Greenhouse's readiness guide with legal and security.
- Schedule a quarterly review of users, permissions, credentials and support access (our cadence).
Candidate data and fraud controls
| Control | What it does (Greenhouse docs) | How to use it (ours) |
|---|---|---|
| Data retention rules | Configure > Privacy & Compliance; Site Admin; days after hire or rejection; fields to anonymise (select Activity Notes separately to remove names there); automatic or manual anonymisation; rejected rules per office | Set periods with legal counsel; start with notifications, then automate |
| Identity verification with CLEAR | Candidates verify in MyGreenhouse using government ID, selfie with liveness and device signals; Greenhouse compares last name, email and phone and flags mismatches; identity data stays with CLEAR | Request at a stage before final interviews for remote roles |
| Fraud Detection | Flags suspicious applications with signals such as location and IP mismatch or invalid contact details | Route flagged applications to a trained reviewer |
| Spam Blocklist | Customer-configured block of IP addresses and email domains | Add sources seen in confirmed fraudulent applications |
For remote technical roles, combine verification with the interview-side checks in the Insider Threat from Fake IT Workers Guide. For candidate access and deletion requests, see the DSAR Guide.
| Organisation profile | Priority choices (ours) |
|---|---|
| Core tier, small recruiting team | Hard-enabled SSO, few Site Admins, Harvest v3 under an Integration System User, retention rules |
| Plus tier, high application volume | Add Fraud Detection, Spam Blocklist and identity verification for remote roles; BIC export of logs |
| Pro tier, regulated or global | Add audit log API to SIEM, Employee ID login where useful, per-office retention rules |
Common misconfigurations
- SSO left soft-enabled: passwords remain a second way in. Plan the hard-enable once agency users are in the identity provider.
- Developer permissions on everyday users: any level can hold them. Review holders of "Manage ALL organization's API Credentials" quarterly.
- v3 credentials created by a person: they fail when that person is deactivated. Use an Integration System User.
- Relying on 30 days of audit history: export continuously so investigations can look further back.
- Org-wide support access left long: choose the shortest duration and own-account scope where possible.
- Retention rules missing Activity Notes: names can remain there. Select Activity Notes in the anonymisation fields.
Apply Greenhouse's release notes and security updates as they are published.
Framework mapping
| Greenhouse control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique it helps address |
|---|---|---|---|
| Hard-enabled SSO, two-step verification | IA-2 | PR.AA-01 | T1078.004 Cloud Accounts |
| Permission levels and developer permissions | AC-6, AC-2 | PR.AA-05 | T1098 Account Manipulation |
| Harvest v3 under an Integration System User, endpoint permissions | SA-9, AC-3 | GV.SC-07 | T1528 Steal Application Access Token |
| Audit log export, Change Log review | AU-2, AU-6 | DE.CM-03, PR.PS-04 | T1213 Data from Information Repositories |
Practitioner checklist
- SSO hard-enabled after a soft-enabled pilot; agency users in the identity provider.
- Three or fewer Site Admins; Job Admin levels and user-specific permissions reviewed quarterly.
- Developer permissions held only by named owners.
- All integrations on Harvest v3 under an Integration System User or partner service account.
- Every credential described with system and owner, its secret in a vault.
- Webhook endpoints and connected integrations reviewed quarterly.
- Support access granted narrowly and audited in the Change Log.
- Audit log (Pro) flowing to the SIEM with alerts on permission changes.
- Data retention rules set for hired and rejected candidates, including Activity Notes.
- Real Talent identity verification and Fraud Detection in use where the tier allows.
Standards and references
- Greenhouse: Understanding permissions in Greenhouse Recruiting
- Greenhouse: Developer permissions
- Greenhouse: Configure single sign-on (SSO) for Greenhouse Recruiting
- Greenhouse: Set up two-step verification
- Greenhouse: Create Harvest API credentials for an integration
- Greenhouse: Connect to Harvest v3 partner integrations
- Greenhouse: Audit log FAQ
- Greenhouse: Configure a data retention rule
Related NHI Mgmt Group resources: Hiring Fraud and Candidate Identity Verification Guide, SaaS API Token Security Guide, SAML Security Guide, DSAR Guide, SaaS Security Guide.