Public TLS trust · Confirmed trust constraint
Check the chain before the next emSign G1 renewal
Announced November 4, 2026. Sources checked November 9, 2026.
Google’s November 4 update says Chrome 153 and higher will stop trusting TLS server certificates chaining to emSign Root CA - G1 when their earliest Signed Certificate Timestamp (SCT) is after November 16, 2026 at 23:59:59 UTC. Certificates with an earliest SCT at or before that cutoff are unaffected by this particular change.
Who it affects. Website operators relying on that public trust chain. This is neither a private-PKI rule nor a new maximum certificate lifetime. The earlier emSign ECC Root CA - G3 removal remains a separate action.
What remains uncertain. The Chrome Root Program says the timing or restrictions may change as its investigation continues. The notice does not establish which chain your next renewal will use.
One next step. Ask the certificate owner and issuer to confirm the renewal chain and, if it depends on G1 beyond the cutoff, plan and test a replacement under another Chrome-trusted hierarchy.
Application sign-in · Gradual rollout
An upgrade alone does not migrate Desktop tokens
Announced November 2, 2026. Sources checked November 9, 2026.
GitHub Desktop can refresh short-lived credentials for API requests and Git operations. The November 2 announcement identifies version 3.6.10 or later and says tokens are issued during sign-in as the rollout reaches an installation.
Who it affects. Eligible accounts on github.com, including Enterprise Cloud. This rollout excludes GitHub Enterprise Server; it is separate from the optional GitHub CLI token preview.
What remains uncertain. Availability is gradual. Upgrading preserves existing sessions and does not migrate their tokens. GitHub gives no rollout-completion date in the announcement.
One next step. Have the desktop-tooling owner plan a small sign-in pilot on a supported version and record the account host, availability and normal Git-operation results before a wider change.
Workflow access · Confirmed schedule; scope wording differs
Review Actions policy before the November brownouts
Announced November 2, 2026. Sources checked November 9, 2026.
GitHub’s November 2 notice adds two pull_request_target brownouts: November 9 and November 16, 2026, 16:00–18:00 UTC. Blocked attempts produce failed runs without executing workflows. The default returns to evaluation mode after each window; permanent enforcement is scheduled for December 2.
Who it affects. The new notice describes public repositories on GitHub Free, Team and Enterprise Cloud unless an applicable event policy explicitly allows the trigger. Private/internal repositories and GitHub Enterprise Server are excluded by that notice.
What remains uncertain. The older announcement and security reference still describe the enforcement cohort as repositories using the default before general availability. The sources differ on breadth, so we cannot determine an individual repository’s inclusion from them alone.
One next step. Assign the workflow owner to inspect the effective policy and available insights, and resolve applicability with GitHub before changing policy. Review any access to secrets and execution of untrusted fork code before considering an exception.
Related
Where to go next
Certificate trust, CLI tokens, and a revised workflow deadline