Sophos Mobile: planera lösenordsregler och säkerhetsprinciper för Windows på ett säkert sätt

Det viktigaste beslutet för Windows-policyer i Sophos Mobile är inte att välja den striktaste inställningen, utan att genomföra ett pilotförsök där återställning är möjlig: bekräfta utgåva och hanteringsstatus, kontrollera BitLocker-återställningen före en eventuell omstart, inventera lokala konton och tilldela först därefter exakt en ändring till en testenhet. En Windows-policy är inte Sophos Fusions Device Encryption-policy och ersätter inte en process för BitLocker-återställning. Se Hantera BitLocker med Sophos Fusion för nyckelhantering och återställning.

Före den första tilldelningen

1. Plattform och omfattning: Målenheten måste faktiskt hanteras som en Windows-dator via Sophos Mobile; enbart Sophos Endpoint Protection innebär inte MDM-registrering. Sophos Mobiles kravlista anger Windows 10/11 Enterprise, Education och Pro, men inte Home. Det är ingen garanti för att varje enskild policykonfiguration fungerar på varje angiven utgåva eller version. Enligt Sophos gäller Restrictions inte för Pro, och Device Guard gäller varken för Pro eller för Windows i S-läge. Kontrollera utgåva, Windows-version, hårdvarukrav och gällande GPO-/MDM-inställningar på just den enheten; en äldre hjälpsida är inte ett aktuellt godkännande.
2. Livscykel: Microsofts support för de vanliga Windows 10-utgåvorna upphörde den 14 oktober 2025. LTSC-/LTSB-utgåvor och enheter med berättigade, aktiverade Extended Security Updates (ESU) måste bedömas separat utifrån utgåva och version. ESU förlänger inte Microsofts produktlivscykel eller ordinarie support, utan ger säkerhetsuppdateringar under en begränsad tid till berättigade och korrekt registrerade enheter. Sophos Mobiles kravlista (version 2026.38 från den 21 september 2026) omfattar ändå Windows 10 Enterprise/Education/Pro från 20H2 samt Windows 11 Enterprise/Education/Pro. Det är en Sophos-lista över plattformar, inte ett löfte om Microsoft-support för äldre Windows 10-versioner och inte ett bevis på att varje Windows-policy fungerar. Även för Windows 11 beror stödet på version och utgåva: exempelvis omfattas 23H2 Pro inte längre av Microsofts uppdateringssupport, medan 23H2 Enterprise/Education har egna tidsgränser. Kontrollera den specifika versionen i Microsofts livscykelinformation för Release Health före pilotförsöket och testa den avsedda inställningen på just denna enhet.
3. Åtkomst och återväg: Ordna en lokal, behörig återställningsåtkomst, tillgänglig hjälp på plats vid enheten och ett ändringsfönster. För BitLocker ska återställningsnyckeln som hör till den berörda enheten och dess aktuella protector vara tillgänglig genom den godkända processen; kontrollera tillgängligheten före ändringen. Betrakta inte en nyckelpost som bara finns registrerad, eller som är inaktuell, som ett test av återställningen. Fastställ först vem som faktiskt hanterar den aktuella BitLocker-återställningsnyckeln för enheten och var den lagras (exempelvis Fusion Device Encryption eller en annan behörig nyckelhantering). Sophos Mobile MDM ensamt visar inte att nyckeln finns i Fusion. Visa inte en produktionsnyckel i Fusion med Show Key enbart för att kontrollera beredskapen. Dokumentera befintliga lösenordskrav och GPO:er. För Device Guard ska du dessutom kontrollera nuläget för VBS/Credential Guard samt Secure Boot och DMA-kapacitet.
4. Liten pilotgrupp: Tilldela inte policyn till en stor enhetsgrupp först. Dokumentera utgångsläge, berörda användare och förväntad synlig ändring. Enligt Sophos finns ingen generell återväg via Uninstall policy för en Windows-policy; inställningar korrigeras genom att uppdatera policyn eller tilldela en annan. En enhet som är utloggad eller inte synkroniserar får inte nödvändigtvis en sådan korrigering direkt.

Lösenordsregler: undvik omstarter och låsta konton

Konfigurationen Password policies styr Maximum number of failed attempts, Time in minutes until the device is locked, Password history och Maximum password age in days.

Time in minutes until the device is locked anger efter hur många minuter utan användning enheten låses. Användaren kan själv låsa upp den igen. Denna inaktivitetslåsning är inte gränsen för misslyckade försök, som kan utlösa en omstart med begäran om BitLocker-återställning. Maximum password age in days anger efter hur många dagar användarna måste ändra sina lösenord.

Password history är antalet tidigare använda lösenord som Sophos Mobile lagrar för att förhindra återanvändning; ett nytt lösenord får inte matcha något av dessa. Sophos tillåter värdet 0 för misslyckade försök, låsningstid och högsta lösenordsålder när respektive begränsning inte ska gälla. Det är ingen rekommendation att stänga av alla skydd: välj värden som passar kontomodellen och möjligheten till återställning, och testa dem var för sig. Lösenordens komplexitet (till exempel längd eller teckenklasser) kan inte ställas in med denna Mobile-policy; den styrs av Windows och beror bland annat på kontotypen. Använd inte specifika komplexitetsvärden från äldre dokumentation som allmängiltiga aktuella Windows-standardvärden.

Om en motsvarande komplexitetspolicy i Windows är aktiverad och faktiskt gäller för det berörda kontot kan lösenordet, när det skapas eller ändras, även kontrolleras mot kontonamnet och delar av det fullständiga namnet eller visningsnamnet. Om och hur dessa namnkontroller gäller beror på den policy som faktiskt gäller och på kontotypen; klarlägg detta för de berörda kontona före pilotförsöket. Detta innebär varken en universell regel för godtyckliga teckenföljder i namn eller ett belägg för dagens krav på Microsoft-konton.

Innan ”Maximum number of failed attempts” aktiveras: Sophos beskriver att Windows-datorn startar om och begär BitLocker-återställning när gränsen nås. Microsoft förtydligar för motsvarande Windows MDM-regel: På en stationär dator raderas inga data; i stället utlöses BitLocker-återställning. Utan aktiverad BitLocker kan regeln inte verkställas. Behandla därför inte en angiven gräns för misslyckade försök vare sig som dataradering eller som ett fungerande skydd på en okrypterad enhet. Kontrollera BitLocker-status och faktiskt tillgänglig återställningsåtkomst på den aktuella enheten före tilldelningen; framkalla inte avsiktligt misslyckade försök på produktionsenheter. Om det utöver användaren som registrerats i Sophos Mobile finns andra lokala användare och minst en av dem inte får ändra sitt lösenord, kan denna Password-policy enligt Sophos inte tilldelas. Kontrollera och korrigera kontobehörigheterna endast i ett separat, godkänt steg; utöka inte användarrättigheter och ta inte bort konton på måfå för att kunna verkställa policyn.

Inventera först konton och befintliga principer för pilotförsöket, välj inaktivitetstid och lösenordsålder utifrån arbetsflödet och bekräfta återställningsberedskapen innan en gräns för misslyckade försök införs. Kontrollera efter tilldelningen med enbart läsåtkomst vilken policy som har kopplats till enheten och om den valda inaktivitetstiden och högsta lösenordsåldern får effekt. Testa gränsen för misslyckade försök endast i en godkänd, isolerad testmiljö med tillgänglig återställningsnyckel. Vid en oväntad BitLocker-återställningsbegäran ska du inte försöka igen eller gissa andra nycklar: matcha enheten med nyckel-ID:t och följ den behöriga återställningsprocessen hos den nyckelhantering som faktiskt ansvarar. Endast om Sophos Device Encryption lagrar den aktuella nyckeln gäller Fusions återställningsprocess.

Restrictions: klarlägg följderna av varje kryssruta i förväg

Restrictions är inte en generell härdning för Pro: Sophos utesluter uttryckligen Windows Pro. Konfigurationen innehåller bland annat Forbid resetting the computer (förhindrar återställning via både Inställningar och Windows RE), Disable VPN settings, Disable Account settings, Forbid Bluetooth, Telemetry level och Forbid manual MDM unenrollment. Särskilt ett blockerat återställningsförfarande eller en blockerad MDM-avregistrering kan hindra planerade support- eller avvecklingsrutiner. Välj bara en motiverad inställning per pilotändring och kontrollera dess funktion på enheten före och efter tilldelningen.

Forbid manual configuration i avsnittet Wi-Fi är särskilt riskabelt: Profiler som användaren redan har konfigurerat, liksom Wi-Fi Sense-profiler, raderas när inställningen tillämpas. Att avmarkera kryssrutan återskapar inte de raderade profilerna automatiskt. Säkerställ före ingreppet en annan, testad åtkomst för hantering och nätverk samt ett dokumenterat sätt att återställa nödvändiga Wi-Fi-profiler. Wi-Fi-profiler, certifikat och SCEP hör till den separata processen för Windows-nätverk och certifikat; aktivera ingen Wi-Fi-blockering här utan detta underlag.

Telemetry level omfattar nivåerna Full, Enhanced, Basic och Security i Sophos lista. Deras faktiska effekt i Windows och om de får användas beror på aktuell utgåva och Microsofts policy; Sophos lista visar inte att varje nivå fungerar på varje pilotenhet. Äldre gränssnittstermer som Cortana eller Wi-Fi Sense är inte heller bevis för någon effekt i aktuella Windows-versioner.

Device Guard: välj först en reversibel väg

Sophos konfiguration Device Guard kan aktivera virtualiseringsbaserad säkerhet (VBS) och Credential Guard. Turn on virtualization-based security (VBS) är det separata fältet för att aktivera VBS; valet under Credential Guard configuration görs separat. Enligt Sophos tillämpas inställningarna första gången Windows-datorn startar efter att policyn har tilldelats. Kontrollera hårdvaran och befintliga GPO-/MDM-inställningar före tilldelning och planera en kontrollerad omstart.

Under Platform security level skiljer Sophos mellan två alternativ:

• Secure Boot använder de skyddsfunktioner som enheten stöder. Utan Input/Output Memory Management Units (IOMMUs) använder VBS UEFI:s Secure Boot-funktion; med IOMMUs använder VBS Secure Boot med skydd mot direkt minnesåtkomst (DMA).
• Secure Boot and DMA protection kräver Secure Boot med DMA-skydd. Om enheten inte stöder DMA-skydd aktiveras inte VBS med detta val.

Förhandskontroll av Credential Guard före tilldelning: Endast om Credential Guard ska aktiveras på pilotenheten ska du kartlägga de inloggnings- och åtkomstvägar som faktiskt används i den aktuella klientmiljön: Wi-Fi eller trådbundet 802.1X, VPN (särskilt PEAP-/EAP-MSCHAPv2), NTLMv1-SSO, RDP/fjärrsupport med sparade Windows-inloggningsuppgifter eller CredSSP samt program som använder obegränsad Kerberos-delegering. Microsoft dokumenterar följderna för autentisering: För MS-CHAP och NTLMv1 kan SSO upphöra att fungera och en ny manuell inloggning behövas; protokollen blockeras inte generellt helt av detta. Certifikatbaserad autentisering för Wi-Fi/VPN blockeras inte. Klienten för fjärrskrivbord kan inte vidarebefordra sparade Windows-inloggningsuppgifter till målvärden; CredSSP kan inte längre använda sparade inloggningsuppgifter eller SSO-uppgifter, medan uttryckligen angivna inloggningsuppgifter fortfarande kan användas. Obegränsad Kerberos-delegering blockeras däremot. Kontrollera ytterligare beroenden endast om de faktiskt förekommer i pilotförsöket: Klarlägg med ansvariga för identitet och program om Kerberos-PKINIT med RSA i stället för Diffie-Hellman eller Kerberos-DES behövs: PKINIT med RSA och DES blockeras av Credential Guard; en ny lösenordsinmatning löser inte dessa fall. Inventera även egna eller icke-Microsoftbaserade Security Support Providers/Authentication Packages (SSP/AP) och program som läser sparade Windows-inloggningsuppgifter: Sådana integrationer kan sluta fungera, särskilt om de behöver LSA-lösenordshashar eller gränssnitt som inte stöds. Kom överens om ett kompatibelt alternativ och ett representativt funktionstest för de åtkomstvägar som faktiskt berörs före tilldelning; tilldela inte Credential Guard om en kritisk åtkomstväg fortfarande är oklar. Bedöm endast de vägar som faktiskt är relevanta för den valda enheten tillsammans med ansvariga för identitet och nätverk; ha oberoende testad åtkomst för hantering eller via lokal konsol och en godkänd återväg utan UEFI-lås redo före omstarten. Om den vanliga nätverks- eller fjärrsupportanslutningen är den enda åtkomstvägen ska Credential Guard inte tilldelas ännu.

Om pilotförsöket kräver att ändringen ska kunna återtas på distans är Credential Guard configuration: Turn on without lock det relevanta valet: Sophos anger Turn off eller en Windows-grupprincip som återväg. Turn on with UEFI lock får inte planeras som en fjärrstyrd inställning som enkelt kan ångras. Sophos anger att avaktivering kräver fysisk närvaro vid datorn; Microsoft dokumenterar ett separat EFI-/startförfarande med bekräftelse före uppstart. Aktivera inte detta läge utan en uttryckligen förberedd lokal återväg. Turn off tar inte bort ett UEFI-lås som redan har satts. Även utan UEFI-lås kan andra hanteringsinställningar åsidosätta ändringen, eller så kan Credential Guard redan vara aktiverat som standard i Windows.

Jämför nuläge och önskat läge på testenheten i System Information (msinfo32.exe) under Virtualization-based Security Services Running: Där måste Credential Guard visas som aktivt om målet med pilotförsöket var att aktivera det. Att en policyuppgift har slutförts bevisar inte att funktionen faktiskt körs. Efter omstarten ska du på den representativa pilotenheten använda ett behörigt testkonto för att kontrollera de tidigare kartlagda inloggningarna och anslutningarna som faktiskt används (särskilt 802.1X/Wi-Fi, VPN, RDP/fjärrsupport och berörda SSO-/delegeringsprogram; om sådana finns även PKINIT-RSA-/DES- och SSP/AP-integrationer samt program som läser sparade Windows-inloggningsuppgifter) och den oberoende återvägen. Dra inte slutsatsen att nätverks- och supportvägar fungerar bara för att Credential Guard körs. Vid avvikelser, kontrollera först utgåva, Secure Boot/DMA, andra policyer och omstartsstatus; experimentera inte genom att slå av och på UEFI-låset. Planera återtagning vid without lock via den förberedda Windows-policyn eller ansvarig GPO, synkronisera enheten och kontrollera läget igen efter omstart. Vid with UEFI lock ska du avbryta och använda den godkända lokala Microsoft-processen för återställning med fysisk åtkomst.

Rulla inte ut e-postkonfigurationer utan kontroll

Mobile-hjälpen listar Email account för Exchange Online/Server och IMAP/POP som Windows-konfigurationer. För platshållare som %_EMAILADDRESS_% och %_USERNAME_% måste fälten Exchange Login och Email Address vara ifyllda för den tilldelade användaren i Sophos Fusion. Om flera Exchange-konton har olika mailbox-policyer kan Windows enligt Sophos endast verkställa en policy; användaren kan dessutom avvisa ändringar i Exchange-konfigurationen. Lösenordsfält i ett policyutkast ersätter inte en godkänd process för identiteter och hemligheter.

Viktig konflikt om aktualitet: Sophos beskriver uttryckligen Exchange-e-postkonfigurationen för Microsofts Mail-app; Microsoft avslutade supporten för Windows Mail/Calendar/People den 31 december 2024 och uppger att e-post och händelser inte längre kan skickas eller tas emot genom dem. Sophos sida om IMAP/POP anger ingen målklient som stöds i dag; det finns inte heller stöd för att anta att konfigurationen automatiskt överförs till nya Outlook. Därför finns här inga steg för produktionsutrullning av denna Mail-app eller en förmodad automatisk överföring till nya Outlook. Fastställ först målklient, autentisering, mailbox-policy och aktuellt stöd i den berörda klientmiljön och testa separat.

Utrullning, kontroll och återtagning

Efter förhandskontrollerna skapar du i Sophos Mobile under Policies > Windows en ny policy avsedd enbart för pilotförsöket. Kontrollera alla tilldelade enheter och grupper innan du redigerar en befintlig policy: Ändringar i en redan tilldelad Windows-policy synkroniseras automatiskt nästa gång enheterna ansluter och är inte ett test på en enskild enhet. Lägg endast till den granskade konfigurationen via Add configuration, spara och välj med Assign enbart den valda pilotenheten. Sidan Schedule task som beskrivs i Sophos dialog är tillgänglig för Android-, Knox- och iOS-policyer, inte för Windows-policyer; utlova därför inte en schemalagd Windows-tilldelning här. Testet börjar alltså inte förrän den ansvariga stödpersonen är redo.

Jämför efter tilldelningen vyn Policies för den berörda enheten, uppgiftsstatus och enhetens faktiska beteende. Windows-policyer synkroniseras automatiskt när enheten ansluter; en visning i gränssnittet bevisar inte i sig att inställningen har fått effekt lokalt. Vid en oväntad ändring ska du inte aktivera ytterligare en säkerhetskritisk inställning: håll enheten åtkomlig, korrigera under kontrollerade former enbart policyn som är reserverad för pilotenheten eller tilldela en granskad ersättningspolicy, invänta synkronisering och nödvändig omstart och kontrollera sedan läget lokalt på nytt. Kontrollera vilka enheter och grupper en gemensam policy har tilldelats innan den ändras. Wi-Fi-profiler som redan har raderats, ett UEFI-lås eller en utlöst begäran om BitLocker-återställning ångras inte automatiskt av detta.

Avgränsning: Rot-/klientcertifikat, SCEP och Wi-Fi-profiler hör till en separat process för Windows-nätverk och certifikat. BitLocker-protectorer och hantering av återställningsnycklar hör till Device Encryption. Kioskläge och Windows-registrering har var för sig egna förutsättningar och återvägar; ingen av dessa uppgifter blir automatiskt utförd av den säkerhetspolicy som granskas här.