I’d recommend using a GitHub App with read-only access to only the repositories that need to be scanned.

That keeps the scanner separate from normal user accounts, avoids creating an external collaborator, and gives you better control over permissions and auditing.

If a GitHub App isn’t supported, a read-only deploy key would be my next choice for simple repository access.

You can invite them as a collaborator, for which they would need a github account.
The other way is a read-only deploy key, however it is limited to one repository.
The best recommended way is using GitHub apps. You can have fine control over what they can do and access with the repo.
I don't know much about working with orgs but here is an ai overview

There are two possibilities.

1. The IT department already has a vulnerability-scanning product with a GitHub App

This is the easiest case.

They give you their GitHub App installation URL. You, as an organization owner/admin, install it into your organization.

During installation, GitHub lets you choose:

All repositories
or
Only select repositories

You'd choose Only select repositories and select the repos they're supposed to scan. GitHub explicitly supports restricting an app installation to selected repositories.

You then review the permissions the app requests. For a scanner that merely needs to clone/read source code, you'd expect something along the lines of:

Repository permissions

Contents: Read-only
Metadata: Read-only

The exact permissions depend on what their scanner needs. GitHub recommends giving an app only the minimum permissions it requires.

2. They want you to create a GitHub App specifically for the scanner

That's also possible, but there's an important distinction.

You could create an app owned by your organization, configure its permissions, and give the IT department the credentials needed to authenticate as that app.

For Git-over-HTTPS, GitHub Apps can use an installation access token as the authentication credential. With the Contents repository permission, that token can be used for HTTP-based Git access.

So conceptually:

GitHub App
│
│ installation
▼
Your organization
│
├── repo1 ✓
├── repo2 ✓
├── repo3 ✓
└── secret-repo ✗

IT scanner
│
└── authenticates as the App

No collaborator account. No personal account. No domain-email exception.

There's another nice property here

You can change what the app can access later.

Organization owners can review installed apps, see their permissions, change repository access, or suspend/delete the app.

So if IT says:

"We need to scan these 14 repositories."

you can give the app those 14 repositories rather than giving some IT account access to the entire organization.

And when the scanning project ends, you remove/suspend the installation.

I all depends whether the IT dept has a github app or you are supposed to make one

Your domain-email rule applies to human accounts, not machine identities — so this is easier than it looks: use a GitHub App, not a collaborator or a key. An app has no user account, so it never touches your "must use a department-domain email" policy.

Two routes, pick one:

A. Their scanner probably already ships as a GitHub App (most SAST / secret-scanning vendors do). Ask them for the installation URL; as an org owner you install it and select "Only select repositories", then grant nothing beyond Contents: Read + Metadata: Read. Done — no human account, no external collaborator, no email exception.

B. If they have no app, create an org-owned GitHub App (Settings → Developer settings → GitHub Apps), give it Contents: Read-only + Metadata: Read-only, install it on only the repos to scan, and hand their scanner an installation token. Same result — an identity that isn't a person.

Why not the alternatives they proposed:

• Read-only deploy key: grants access to one repo per key (tedious across many repos), and on GitHub Enterprise org admins can restrict deploy-key usage org-wide. Fine for 1–2 repos, but the App scales and audited better.
• "Read-only collaborator": there's no role that dodges the account requirement — GitHub's lowest role (Read, formerly triager) still demands a real GitHub user, which breaks your domain-email rule. Skip it.

So: GitHub App, scoped to selected repos, Contents + Metadata read-only — that's the option that fits your constraints exactly.

Good — the App route it is. On your follow-up (“don't they already have access through the portal?”): usually no, not in the way that matters here — because granting access ≠ reading repository contents.

Your IT department runs the portal that provisions your identities — SSO, which accounts may sign in, group entitlements. That's the identity & access-management layer: it lets them decide who may log in, but it does not automatically give any of their accounts (or their scanner) read access to the files in your repos. Reading repository contents is a separate grant — org membership/role, an outside collaborator, a deploy key, or a GitHub App installation.

The GitHub App you're about to install is exactly that second, scoped grant: it lets their scanner read only the selected repos' contents — and nothing else — while the portal still controls the human logins. It also gives you an audit trail of everything the app touched, which an umbrella "they probably already have access" wouldn't give you.

So no conflict. If anything, you can tell them the App scoped to selected repos (Contents + Metadata read-only) is the least-privilege way to do it — that phrasing generally lands well with an IT/security team. 👍

Recommended Architecture for Enterprise Cross-Department Read-Only Scans

Since your department enforces strict domain-email controls for human user accounts, traditional outside collaborators are not an option. Here is the safest, most scalable way to proceed without violating your domain policies:

Recommended Solution: GitHub App (Scoped Installation)

A GitHub App operates as a machine identity (bot/system token), so it never requires a human GitHub user account or a department-domain email address.

1. Option A (If IT already uses an enterprise scanner tool):

   • Ask IT for their scanner’s GitHub App installation URL.
   • As an Organization Owner/Admin, open the URL and select "Only select repositories" to grant access strictly to the target repos.
   • Verify requested permissions are minimal: Repository permissions -> Contents: Read-only and Metadata: Read-only.

2. Option B (If IT needs raw Git clone access via HTTP):

   • Go to Organization Settings -> Developer settings -> GitHub Apps -> New GitHub App.
   • Name: IT-Vulnerability-Scanner.
   • Set permissions: Contents: Read-only & Metadata: Read-only.
   • Create the app, install it on your organization choosing "Only select repositories", and generate an installation access token or private key for IT's scanner pipeline.

Why Other Proposed Options Should Be Avoided:

• Read-Only Collaborator: Requires a real GitHub user account, which violates your rule that all accounts must use your department’s domain email.
• Read-Only Deploy Keys: Deploy keys are bound to a single repository. If IT needs access to 10+ repos, managing and rotating individual SSH keys per repository becomes an administrative burden and security risk.
• Enterprise Portal Access: Access control via your IT department's SSO portal manages identity authentication (login rights), but does not automatically grant repository data read access. Granting access via a scoped GitHub App preserves the principle of least privilege and keeps full audit logs.

Since they don't have one, here's the concrete version of route B, plus a lighter fallback:

B. Create your own org-owned GitHub App (org owner, ~10 min):

1. Org Settings → Developer settings → GitHub Apps → New GitHub App.
2. Name it (e.g. DOH-vuln-scan-read), any homepage URL (your portal is fine), and leave webhooks off/unused.
3. Permissions → Repository: Contents: Read-only + Metadata: Read-only. Nothing else.
4. "Where can this GitHub App be installed?" → Only on this account. Create it.
5. Generate the private key (.pem) — that's the credential. Then Install App → Only select repositories → pick the repos to scan.
6. Their scanner authenticates by minting short-lived installation tokens (POST /app/installations/{id}/access_tokens). Many scanners support "GitHub App" auth natively — worth asking them before writing any code.

Lighter fallback if that's too much setup: a fine-grained personal access token on a dedicated service account that has a department-domain email. That still satisfies your "domain accounts only" rule, can be scoped to only the repos to scan with Contents: Read-only, needs no interactive login after creation, and has an expiry you control. Less elegant than an App, but near-zero setup. (The org just needs to allow fine-grained PATs on its Actions/access policy — usually the default.)

Either way the scanner never needs a human seat. 👍

From what you described, I think the main question is whether the IT department needs people to access the repos or whether they have an automated scanner that needs access.

If it’s just specific IT users who need to look at or clone the repos, giving them read-only access should be enough. They’d be able to see the code without being able to push changes.

If it’s an automated vulnerability scanner, then a read-only deploy key or a properly scoped token would probably make more sense.

The only part I’d double-check is your enterprise policy. Since you said everyone currently has to use an account with your department’s email domain, you’ll want to confirm whether IT users can be added as external collaborators or whether your enterprise settings prevent that.

I definitely wouldn’t give them write or admin access just for vulnerability scanning. They should only get whatever access the scanner actually needs.