Runbook: Twingate Device Compliance Certificates

Priority: Week 2 roadmap item
Tenant: Azure PROD — ciriusgroup.com (d477c9f8)
Admin portals: https://intune.microsoft.com · https://auth.twingate.com (sign in with Twingate admin account from Keeper)
Related runbooks: Twingate Operations · Twingate Compliance Enforcement · Intune Daily Management · Conditional Access Reference

1. What Device Compliance Certs Are and How They Work

The mechanism

Twingate supports mutual TLS (mTLS) device authentication. When device certificate enforcement is enabled, the Twingate client must present a valid X.509 device certificate during the TLS handshake to the Twingate gateway — before any resource access is evaluated. Twingate verifies:

The certificate is signed by a CA that Twingate has been configured to trust
The certificate is not expired or revoked
Subject attributes in the cert match expected values (typically the device's serial number or Entra device ID embedded in the Subject CN or SAN)

If the certificate is absent, expired, or signed by an untrusted CA, the connection is dropped at the handshake layer — the user never gets to an authentication prompt.

Why it is stronger than Intune compliance CA policy alone

The current setup enforces:

Entra Conditional Access — requires "Compliant device" signal from Intune before granting Twingate app tokens
Twingate–Intune integration — Twingate reads Intune compliance state and requires "Compliant" at connection time

What this does not prevent: credential theft plus an attacker-controlled device. An attacker with a stolen Entra credential can enroll a fake device in Intune (if enrollment restrictions are not airtight), mark it compliant (if the compliance policy evaluates quickly), and then authenticate to Twingate from that device.

Device compliance certificates close this gap by requiring proof of a specific managed device identity — one that received a certificate through Intune's SCEP pipeline, which only runs on devices that were already enrolled before the SCEP profile fires. An attacker with stolen credentials cannot get a certificate on their unmanaged device because the SCEP enrollment requires a valid Intune device context.

The combination: credentials + compliant Intune state + device cert from the Intune SCEP pipeline = three independent signals that must all be valid simultaneously.

2. Current State vs. Target State

Current state

Control	Status
Twingate as primary remote access	Enforced — all non-CEO/CTO remote access
Entra SSO for Twingate authentication	Enforced
Intune compliance policy (BitLocker, AV, patch floor, screen lock)	Enforced
Conditional Access: require Compliant device for Twingate app	Enforced
Twingate–Intune posture integration (trust scoring)	Enforced
Device certificate requirement in Twingate	Not configured
SCEP certificate profile in Intune	Not deployed
CA cert uploaded to Twingate	Not done

Target state

Control	Status
All of the above	Enforced
Intune SCEP profile deployed to all managed Windows devices	Deployed
Device cert auto-enrolled on all Intune-managed Windows endpoints	Deployed
CA cert (Intune SCEP CA) uploaded and trusted in Twingate	Configured
Twingate requires device cert for resource access	Enforced per network/resource

3. Setting Up the CA

Options

Option	How it works	Complexity	Recommendation for Cirius
On-premises Microsoft CA via NDES	NDES proxy on-prem issues certs via SCEP; Intune drives enrollment	High — requires on-prem Windows Server with NDES role, IIS, and an AD CS hierarchy	No — adds on-prem dependency; Cirius does not need it
Intune SCEP with cloud CA (PKCS via DigiCert or GlobalSign)	Third-party cloud CA issues certs; Intune PKCS profiles drive enrollment	Medium — requires commercial CA contract	No — unnecessary cost for this use case
Azure AD Certificate-Based Authentication (Entra CBA)	Entra issues certs for user authentication to Entra itself	Low — native to Entra	No — Entra CBA authenticates users, not devices; wrong layer
Intune SCEP with Intune Certificate Connector (recommended)	Intune Certificate Connector on a Windows Server acts as SCEP proxy to an on-prem or cloud CA; Intune drives device cert enrollment	Medium — requires one Windows Server with the Connector, but no NDES role	Yes
Intune PKCS with Microsoft CA (simplest if you have on-prem CA)	If an on-prem CA exists, Intune PKCS profiles can pull certs directly via the Intune Certificate Connector	Low-medium — connector-only, no NDES	Preferred if on-prem CA exists

Recommended path for Cirius

Use Intune SCEP with the Intune Certificate Connector backed by either:

An existing on-prem Microsoft CA if one exists in the AD environment (check: certutil -config - -ping on any domain-joined machine)
Or a new standalone Windows CA purpose-built for this (a VM, not a domain root CA)

The Intune Certificate Connector (formerly NDES Connector) installs on a Windows Server in the domain. It does not need the NDES Windows role — the connector handles the SCEP endpoint itself as of connector version 6.x+. This eliminates the main complexity of the old NDES path.

If no on-prem CA exists: Stand up a new Windows Server VM (vm-intune-scep-ca-01) as a standalone root CA or subordinate CA. This does not need to be a domain controller. Keep it minimal — its only job is signing device certificates.

CA cert sizing recommendations

Algorithm: RSA 2048 minimum; RSA 4096 or ECDSA P-256 preferred
CA cert validity: 10 years (root/standalone), 5 years (subordinate)
Issued cert validity: 1 year (see section 4)
CRL/OCSP: Enable CRL publication to an HTTP endpoint reachable by Twingate's validation path. If CRL is not reachable by Twingate, revocation checking will fail open or hard-fail depending on Twingate's configuration — clarify with Twingate support before go-live.

4. Intune SCEP Certificate Profile

Step-by-step: create the profile

Path: Intune Admin Center → Devices → Configuration → Create → New Policy

Platform: Windows 10 and later
Profile type: Templates → SCEP certificate
Click Create

Basics tab

Field	Value
Name	`Twingate-Device-Cert-Windows`
Description	`Device identity certificate for Twingate mTLS enforcement. Deployed to all Intune-managed Windows endpoints.`

Configuration settings tab

Setting	Value	Notes
Certificate type	Device	Not User — this cert identifies the machine, not the person
Subject name format	`CN=`	Embeds the Entra/Intune device ID in the CN; Twingate uses this to identify the device. Alternative: `CN=` if you prefer hardware serial as the anchor
Subject alternative name	URI =	Adds the device ID as a URI SAN — some Twingate versions match on SAN rather than CN
Certificate validity period	1 year (365 days)	Balances lifecycle management with credential hygiene; Intune auto-renews before expiry if renewal threshold is set
Renewal threshold (%)	20	Renewal kicks off when 20% of validity remains (~73 days before expiry on a 1-year cert) — gives plenty of buffer
SCEP server URLs	`https://<your-connector-host>/certsrv/mscep/mscep.dll`	The FQDN of the Windows Server running the Intune Certificate Connector; must be reachable from managed devices
Key storage provider (KSP)	TPM KSP if TPM is present, otherwise Software KSP	Binds the private key to the device TPM where available — increases assurance that the cert cannot be exported from the device
Key usage	Digital signature	Device auth certs need only digital signature; do not enable key encipherment unless your CA template requires it
Key size (bits)	2048	Minimum; increase to 4096 if your CA supports it without performance issues
Hash algorithm	SHA-2
Root certificate	Select the trusted root cert profile you create in the next step	The SCEP profile depends on a Trusted Certificate profile that pushes the CA cert to the device's Trusted Root store
Extended key usage	Add: Client Authentication (OID 1.3.6.1.5.5.7.3.2)	Marks the cert as valid for client auth — required for mTLS

Assignments tab

Setting	Value
Assign to	All Devices (filtered to Windows, Intune-enrolled)
Exclude groups	None initially; add exception groups if needed during rollout

Note: You must also create a Trusted Certificate profile that deploys the CA root certificate to the device's Trusted Root store before the SCEP profile can enroll. Create this first.

Step-by-step: create the Trusted Certificate profile (prerequisite)

Path: Intune Admin Center → Devices → Configuration → Create → New Policy

Platform: Windows 10 and later
Profile type: Templates → Trusted certificate
Upload your CA root certificate (.cer / DER format)
Destination store: Computer certificate store — Root
Assign to All Devices (same scope as the SCEP profile)

Deploy the Trusted Certificate profile before the SCEP profile. The SCEP profile depends on it.

Verifying cert deployment on a device

After the Intune sync cycle (up to 1 hour for new profiles):

powershell

# Run on the managed device as local admin or via Intune remediation script
# Check that the device cert is in the machine's Personal store
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {
    $_.Subject -like "*DeviceId*" -or $_.Issuer -like "*Intune*" -or $_.Issuer -like "*<your CA name>*"
} | Select-Object Subject, Issuer, NotBefore, NotAfter, Thumbprint

# Verify Extended Key Usage includes Client Authentication (1.3.6.1.5.5.7.3.2)
Get-ChildItem -Path Cert:\LocalMachine\My | ForEach-Object {
    $eku = $_.EnhancedKeyUsageList
    if ($eku.ObjectId -contains "1.3.6.1.5.5.7.3.2") {
        [PSCustomObject]@{
            Subject    = $_.Subject
            Thumbprint = $_.Thumbprint
            NotAfter   = $_.NotAfter
            EKU        = ($eku | Select-Object -ExpandProperty FriendlyName) -join ", "
        }
    }
}

Check Intune deployment state:
Intune Admin Center → Devices → Configuration → Twingate-Device-Cert-Windows → Device and user check-in status

Expected: all enrolled Windows devices show Succeeded. Devices showing Pending have not checked in yet. Devices showing Error — see Troubleshooting section.

5. Configuring Twingate to Require Device Certificates

Step 1 — Upload the CA certificate to Twingate

Path: Twingate admin console → Settings → Device Security → Certificate Authorities → Add CA

Export your CA root certificate as a PEM file (.pem or .crt)
Upload via the Add CA button
Twingate will now trust device certificates signed by this CA

If you have a subordinate CA, upload both the root and the subordinate CA certs. Twingate needs the full chain to validate issued device certs.

Verify the CA appears under Settings → Device Security → Certificate Authorities with status Active.

Step 2 — Enable certificate requirement per network or resource

Twingate allows you to require device certs at two levels:

Option A — Per remote network (recommended for initial rollout):
Networks → cirius-dmz → Security → Device Authentication → Require Client Certificate → On

This requires a valid device cert for any resource accessed through the cirius-dmz connector pool.

Option B — Per resource (more granular):
Resources → <resource name> → Security → Device Authentication → Require Client Certificate → On

Use Option B if you want to enforce device certs only on Tier 0 / Tier 1 resources during phased rollout before enabling it across all resources.

Step 3 — Configure the cert attribute check (optional but recommended)

If Twingate supports attribute filtering on the cert subject (verify in your Twingate plan level — this may be a feature of the Business/Enterprise tier):

Settings → Device Security → Certificate Policies → Add Policy

Set the policy to:

Subject CN must match: pattern, or
Issuer must match: your CA's distinguished name

This prevents a cert from any client-auth-enabled source being accepted — only certs from your Intune SCEP pipeline, with the expected subject format, pass.

What the user experience looks like

Managed device with cert: Twingate client connects normally. The cert is presented automatically from the machine's Personal cert store during the TLS handshake. The user sees no additional prompts.
Unmanaged device (no cert): Twingate client fails to connect with a "Device not authorized" or "Certificate required" error. The user cannot proceed.

6. Testing

Verify: compliant managed device can connect

On a device with the Intune cert deployed:

Confirm the cert is present (run the PowerShell verification from section 4)
Open the Twingate client → confirm it shows Connected
Attempt to access a resource in the Twingate network
Confirm access succeeds
In Twingate admin console → Logs — find the connection event and verify the log shows Certificate validated or similar indication that cert auth succeeded

Verify: unmanaged device is blocked

Use a personal or test machine that is not Intune-enrolled and has no device cert from your CA:

Install the Twingate client
Sign in with a valid corporate Entra account (MFA if required)
Attempt to connect
Expected result: connection fails — Twingate should return a Device not authorized error or TLS handshake failure
Confirm in Twingate Logs that the connection attempt was rejected with a certificate-related reason

If the unmanaged device connects successfully, device cert enforcement is not active — recheck the network/resource setting from step 2 above.

Verify: cert rejection on expired cert

On a test machine, temporarily set the system clock forward past the cert expiry date (or use a test cert with a short validity period), then attempt to connect. Expected: Twingate rejects the connection. Reset the clock after the test.

7. Troubleshooting

Cert not deploying — Intune SCEP errors

Check: Intune Admin Center → Devices → Configuration → Twingate-Device-Cert-Windows → Device and user check-in status → filter by Error

Common error codes and fixes:

Symptom	Likely cause	Fix
Error 0x80094800 / CERTSRV_E_NO_CERT_TYPE	SCEP URL unreachable from device	Verify the Connector server FQDN is resolvable and port 443 is open from device network to the Connector server
Certificate profile shows Pending for >2 hours	Device hasn't checked in	Trigger manual sync: Intune Admin Center → Devices → select device → Sync; also run `dsregcmd /status` on device to verify Entra join is healthy
Profile deploys but cert not in cert store	Trusted Certificate profile not deployed first	Verify the Trusted Cert profile shows Succeeded on the same device; the SCEP profile depends on the root cert being in the Trusted Root store
SCEP server returns HTTP 403	Intune Certificate Connector not configured for the right CA template	On the Connector server, open the Intune Certificate Connector service config and verify the CA and template name match your CA setup
Event log errors on the Connector server	Connector service failing	On the Windows Server running the Connector: Event Viewer → Applications and Services Logs → Microsoft → Intune → CertificateConnector — errors here describe the exact failure

Check Intune SCEP diagnostic logs on the device:

powershell

# SCEP request logs on the managed device
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" |
    Where-Object { $_.Message -like "*SCEP*" -or $_.Message -like "*certificate*" } |
    Select-Object TimeCreated, Id, Message -First 30

Cert deployed but Twingate rejects it

Symptom: Device has a valid cert in Cert:\LocalMachine\My but Twingate returns a certificate error or "device not authorized."

Work through in order:

CA not uploaded to Twingate: Go to Settings → Device Security → Certificate Authorities and confirm your CA is listed and Active. If the CA cert shown there does not match the Issuer in the device cert, they are mismatched.

Full chain not uploaded: If you have a root CA and a subordinate/issuing CA, both must be uploaded. Verify the cert chain:

powershell

# Show the full chain for the device cert
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*DeviceId*" } | Select-Object -First 1
$cert.GetIssuerName()
# Then verify that issuer cert is in Trusted Root store
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*<your CA name>*" }

EKU mismatch: The cert must have Client Authentication (1.3.6.1.5.5.7.3.2) in the EKU. If the CA template used during SCEP enrollment did not include this OID, the cert will fail mTLS. Fix by correcting the CA template and re-enrolling.
Subject format mismatch: If you configured a Twingate certificate policy requiring a specific subject CN pattern, verify the issued cert's CN matches. Run:
powershell
```
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*DeviceId*" } | Select-Object -First 1
$cert.Subject
```
Twingate client version: Older client versions may not support mTLS cert auth. Verify client is on the latest release. Twingate admin console → Devices → select device → Client version.
Wrong cert store: Twingate reads from Cert:\LocalMachine\My (Computer Personal store). If the cert landed in Cert:\CurrentUser\My (User Personal store), Twingate won't find it. The Intune SCEP profile's Certificate type = Device setting should write to the machine store — but verify with the PowerShell check above using LocalMachine\My.

Twingate shows device as untrusted despite cert

Symptom: User can connect (cert auth passes) but device trust level shows Low in the Twingate admin portal.

Certificate enforcement and trust scoring are separate systems. The device cert proves the device is managed — it does not automatically set trust level. Trust level still comes from the Intune compliance posture integration. Check:

Intune Admin Center → Devices → select device → Compliance — does the device show Compliant?
Twingate admin console → Devices → select device — does it show the Intune integration data?
If Intune integration is not reflecting compliance: in Twingate → Settings → Device Security → Integrations → Microsoft Intune — check the last sync time and re-authorize the Graph API connection if stale.

8. Rollout Strategy

The goal is to add device cert enforcement without locking out existing compliant users. The risk is that some managed devices may not have received the SCEP cert yet when enforcement turns on.

Phase 0 — Deploy SCEP profile, collect cert deployment data (Week 2, days 1–3)

Deploy the Trusted Certificate profile to All Devices
Deploy the SCEP Certificate profile to All Devices
Wait 48–72 hours for Intune sync cycles to reach all devices
Run the PowerShell cert check below across all devices to measure coverage:

powershell

# Run as a Proactive Remediation script in Intune (detection script, read-only)
# Returns "Compliant" if cert is found, "NonCompliant" if not
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {
    $_.Issuer -like "*<your CA name>*" -and
    $_.NotAfter -gt (Get-Date) -and
    ($_.EnhancedKeyUsageList.ObjectId -contains "1.3.6.1.5.5.7.3.2")
}
if ($cert) {
    Write-Output "Compliant"
    exit 0
} else {
    Write-Output "NonCompliant"
    exit 1
}

Path to create Proactive Remediation: Intune Admin Center → Devices → Scripts and remediations → Remediations → Create → add detection script above → assign to All Devices

This gives you a report of which devices have the cert and which do not — without enforcing anything yet.

Phase 1 — Enable cert requirement in report-only / scoped enforcement (Week 2, days 4–5)

Enable device cert requirement on a test resource or a test remote network (not the main cirius-dmz network)
Have Rory, Kevin, and Greg test connectivity from their managed devices
Confirm cert-present devices connect; confirm a personal/unmanaged device is blocked

Phase 2 — Enforce on Tier 0 and Tier 1 resources only (Week 3)

Once ≥ 95% cert deployment coverage confirmed from Phase 0 Proactive Remediation report
Enable cert requirement on Tier 0 and Tier 1 resources in Twingate
Monitor Twingate access logs for unexpected failures
Give 48 hours before expanding — watch for help desk tickets from legitimate users who were missed

Phase 3 — Enforce across all resources (Week 3–4)

Expand cert requirement to the full cirius-dmz remote network
Devices without the cert are now blocked until the SCEP profile deploys to them
Any device that has been offline for the entire rollout period will need to check in to Intune before it can connect — communicate this to users if devices were unused for a long time

Communication to users

Before Phase 2 enforcement:

Send an email (Microsoft Teams message is fine) explaining that Twingate will require a managed device starting <date>
Tell users that if they try to connect from a personal computer, it will be blocked — and that this is intentional
Tell users that their managed laptop does not need any action from them — the cert is installed automatically

Rollback

If cert enforcement causes unexpected broad outages:

Twingate admin console → Networks → cirius-dmz → Security → Device Authentication → Require Client Certificate → Off
Effect: immediate — next connection attempt succeeds without cert
Investigate the failure (was it a SCEP deployment gap? A CA mismatch?)
Do not re-enable until the root cause is identified and the SCEP deployment coverage is verified

9. Certificate Lifecycle

Renewal

The Intune SCEP profile's renewal threshold (20%) setting causes Intune to automatically re-enroll the device certificate when 20% of its validity period remains (approximately 73 days before expiry on a 1-year cert). This happens without user intervention.

What happens during renewal:

Intune detects the cert is in the renewal window
A new SCEP enrollment request is sent to the Connector
A new cert with a new thumbprint and extended expiry is issued and placed in Cert:\LocalMachine\My
The old cert remains until it expires or is cleaned up by Intune

No user action required. No Twingate reconfiguration required — the new cert is issued by the same CA, which is already trusted in Twingate.

What happens when a cert expires

If a device certificate expires before Intune renews it (device was offline, SCEP profile was removed, Connector was down), Twingate will reject the connection at the handshake layer. The user will see a connection failure.

Recovery:

Reconnect the device to the corporate network or a network where it can reach the Intune service
Trigger an Intune sync: Settings → Accounts → Access work or school → ciriusgroup.com → Info → Sync (on the device)
Or from Intune Admin Center: Devices → select device → Sync
Wait up to 30 minutes for the SCEP re-enrollment to complete
Verify new cert in Cert:\LocalMachine\My
Twingate connectivity resumes automatically

Monitoring for upcoming expirations

The operational agent in the security monitoring fleet can be extended to query the cert expiry state via Intune Graph API. Until that agent is built, run this query monthly:

powershell

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

# Get all SCEP-deployed cert device statuses — check for devices approaching expiry
# Adjust the profile ID to match your SCEP profile's object ID
$profileId = "<your-scep-profile-object-id>"  # From Intune Admin Center URL when viewing the profile
$statuses = Get-MgDeviceManagementDeviceConfigurationDeviceStatus -DeviceConfigurationId $profileId
$statuses | Where-Object { $_.Status -ne "success" } | Select-Object DeviceDisplayName, Status, LastReportedDateTime

For certificate expiry tracking from the device side, run as a Proactive Remediation:

powershell

# Detection script — flags if cert expires within 90 days
$threshold = (Get-Date).AddDays(90)
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {
    $_.Issuer -like "*<your CA name>*" -and
    ($_.EnhancedKeyUsageList.ObjectId -contains "1.3.6.1.5.5.7.3.2")
} | Sort-Object NotAfter | Select-Object -First 1

if (-not $cert) {
    Write-Output "No device cert found"
    exit 1
}
if ($cert.NotAfter -lt $threshold) {
    Write-Output "Cert expires $($cert.NotAfter) — within 90-day threshold"
    exit 1
}
Write-Output "Cert valid until $($cert.NotAfter)"
exit 0

Add this as a Proactive Remediation without a remediation script (detection-only) so it surfaces in the Intune report without taking action — the SCEP profile handles renewal automatically. Review the report monthly as part of the Monthly Security Review.

CA certificate expiry

The CA root certificate itself has a longer validity period (10 years if you follow the sizing recommendation in section 3). Set a calendar reminder for CA cert expiry 2 years before expiry. If the CA cert expires:

All device certs it signed become untrusted
All Twingate connections requiring device cert enforcement will fail simultaneously
Recovery requires generating a new CA cert, re-uploading to Twingate, and re-issuing all device certs via a new SCEP profile deployment

This is why the 10-year CA validity and the 90-day monitoring alert threshold are important — no surprises.

Document History

Date	Change	Author
May 2026	Initial draft — device compliance cert setup for Twingate, Intune SCEP profile, rollout plan, lifecycle ops	Rory

Runbook: Twingate Device Compliance Certificates ​

1. What Device Compliance Certs Are and How They Work ​

The mechanism ​

Why it is stronger than Intune compliance CA policy alone ​

2. Current State vs. Target State ​

Current state ​

Target state ​

3. Setting Up the CA ​

Options ​

Recommended path for Cirius ​

CA cert sizing recommendations ​

4. Intune SCEP Certificate Profile ​

Step-by-step: create the profile ​

Basics tab ​

Configuration settings tab ​

Assignments tab ​

Step-by-step: create the Trusted Certificate profile (prerequisite) ​

Verifying cert deployment on a device ​

5. Configuring Twingate to Require Device Certificates ​

Step 1 — Upload the CA certificate to Twingate ​

Step 2 — Enable certificate requirement per network or resource ​

Step 3 — Configure the cert attribute check (optional but recommended) ​

What the user experience looks like ​

6. Testing ​

Verify: compliant managed device can connect ​

Verify: unmanaged device is blocked ​

Verify: cert rejection on expired cert ​

7. Troubleshooting ​

Cert not deploying — Intune SCEP errors ​

Cert deployed but Twingate rejects it ​

Twingate shows device as untrusted despite cert ​

8. Rollout Strategy ​

Phase 0 — Deploy SCEP profile, collect cert deployment data (Week 2, days 1–3) ​

Phase 1 — Enable cert requirement in report-only / scoped enforcement (Week 2, days 4–5) ​

Phase 2 — Enforce on Tier 0 and Tier 1 resources only (Week 3) ​

Phase 3 — Enforce across all resources (Week 3–4) ​

Communication to users ​

Rollback ​

9. Certificate Lifecycle ​

Renewal ​

What happens when a cert expires ​

Monitoring for upcoming expirations ​

CA certificate expiry ​

Document History ​

Runbook: Twingate Device Compliance Certificates

1. What Device Compliance Certs Are and How They Work

The mechanism

Why it is stronger than Intune compliance CA policy alone

2. Current State vs. Target State

Current state

Target state

3. Setting Up the CA

Options

Recommended path for Cirius

CA cert sizing recommendations

4. Intune SCEP Certificate Profile

Step-by-step: create the profile

Basics tab

Configuration settings tab

Assignments tab

Step-by-step: create the Trusted Certificate profile (prerequisite)

Verifying cert deployment on a device

5. Configuring Twingate to Require Device Certificates

Step 1 — Upload the CA certificate to Twingate

Step 2 — Enable certificate requirement per network or resource

Step 3 — Configure the cert attribute check (optional but recommended)

What the user experience looks like

6. Testing

Verify: compliant managed device can connect

Verify: unmanaged device is blocked

Verify: cert rejection on expired cert

7. Troubleshooting

Cert not deploying — Intune SCEP errors

Cert deployed but Twingate rejects it

Twingate shows device as untrusted despite cert

8. Rollout Strategy

Phase 0 — Deploy SCEP profile, collect cert deployment data (Week 2, days 1–3)

Phase 1 — Enable cert requirement in report-only / scoped enforcement (Week 2, days 4–5)

Phase 2 — Enforce on Tier 0 and Tier 1 resources only (Week 3)

Phase 3 — Enforce across all resources (Week 3–4)

Communication to users

Rollback

9. Certificate Lifecycle

Renewal

What happens when a cert expires

Monitoring for upcoming expirations

CA certificate expiry

Document History