E-postkontoen kan brukes til passordtilbakestilling, kundedialog, fakturaer og tilgang til andre systemer. Derfor må virksomheten beskytte mer enn selve passordet: innlogging, aktive økter, gjenoppretting og administratorene som kan nullstille kontoen.

Denne guiden gir en enkel policy for e-postkontoer. Den bredere sjekklisten for e-postsikkerhet dekker også DNS, betaling, enheter, backup og respons.

Kort anbefaling

SituasjonFørstevalgReserve
Tjenesten støtter passkey eller sikkerhetsnøkkelregistrer minst to kontrollerte innloggingsnøkleroppbevar gjenopprettingskode separat
Tjenesten støtter passord og MFAunikt passord fra passordmanager og sterkeste MFA-metodekontrollert gjenoppretting
Tjenesten støtter bare passordlangt, unikt og tilfeldig passordprioriter utfasing eller risikoreduserende kontroll
Flere trenger samme innbokspersonlige brukere med delt postkasse eller delegeringdokumentert gruppe eller alias
Teknisk system må sende e-postegen begrenset systemidentitetdedikert nøkkel eller token når plattformen støtter det

Bruk aldri én felles innlogging til både daglig e-post og administrasjon.

Hva er et godt passord?

Et godt passord er først og fremst unikt, langt nok og vanskelig å gjette. Det skal ikke inneholde virksomhetsnavnet, e-postadressen, årstall, produktnavn eller en variant av et gammelt passord.

For et passord som er eneste innloggingsfaktor, er minst 15 tegn en god nedre grense. Det følger NISTs gjeldende krav til passordbasert innlogging . Lengde alene gjør likevel ikke virksomhetsnavn2026! trygt; angripere prøver forutsigbare mønstre først.

La passordmanageren generere kontopassord

For kontoer du ikke må skrive manuelt:

  1. La passordmanageren generere et tilfeldig passord.
  2. Bruk så lang verdi som tjenesten støtter uten å ødelegge eldre integrasjoner.
  3. Lagre riktig innloggingsadresse sammen med passordet.
  4. Slå på MFA og lagre gjenopprettingskodene kontrollert.
  5. Test innlogging og gjenoppretting før den gamle tilgangen fjernes.

Ikke gjør tilfeldige passord lettere å lese ved å gjenbruke et fast mønster mellom tjenester.

Bruk en lang passfrase når den må huskes

Masterpassordet til passordmanageren må ofte huskes. Bruk en lang passfrase med flere tilfeldig valgte ord som ikke danner et kjent sitat eller en personlig setning. Ikke bruk eksempler fra en nettside ordrett.

Biometri eller PIN som åpner en lokal enhet er ikke det samme som kontopassordet. Enheten kan ha egne krav og sperrer mot mange forsøk.

Unngå gamle passordregler

NIST anbefaler at tjenester ikke krever bestemte blandinger av store bokstaver, tall og symboler, og ikke tvinger periodisk passordbytte uten tegn på kompromittering. Slike regler fører ofte til forutsigbare varianter.

Bytt passord når:

  • det er gjenbrukt eller delt
  • det finnes i en kjent lekkasje
  • noen kan ha sett eller mottatt det
  • en enhet, konto eller leverandør er kompromittert
  • en person med tilgang slutter eller bytter rolle
  • leverandøren krever bytte etter en konkret hendelse

Ved mistanke om kontoovertakelse er passordbytte alene utilstrekkelig. Tilbakekall økter og tokens, fjern ukjent MFA og gjenoppretting, kontroller videresending og innboksregler, og undersøk administratorendringer.

Blokker kjente og lekkede passord

En virksomhet som selv tilbyr innlogging, bør kontrollere nye passord mot en blokklist med vanlige, forventede og kompromitterte verdier. Ikke avvis vilkårlige delord; forklar hvorfor hele passordet ble avvist.

En bruker kan undersøke om en e-postadresse finnes i kjente datalekkasjer hos Have I Been Pwned . Ikke skriv et aktivt passord inn på en tilfeldig nettside for å teste det. Et treff på e-postadressen betyr heller ikke automatisk at dagens passord er lekket; vurder hvilken tjeneste, hvilke data og hvilket tidspunkt treffet gjelder.

Velg passordmanager for virksomheten

Ikke velg bare etter logo eller pris. Test:

  • bedriftsstyrte brukeridentiteter og roller
  • MFA eller passkey for selve hvelvet
  • kontrollert deling uten å sende passordet i e-post eller chat
  • hendelseslogg og varsler etter behov
  • sperring og overføring ved avslutning
  • gjenoppretting uten at én privat telefon er eneste vei inn
  • eksport i et dokumentert format
  • klientstøtte, oppdateringsrutine og leverandørens sikkerhetsmodell
  • databehandlerforhold og krav til lagring der det er relevant
  • nødkonto og testet beredskap

Importer passord kontrollert. En eksportfil fra nettleser eller gammel manager kan inneholde alle passord i klartekst. Oppbevar den bare mens migreringen pågår, kontroller importen og slett filen sikkert fra alle kopier etterpå.

MFA: ranger metodene etter phishing-motstand

Når leverandøren tilbyr flere metoder, prioriter:

  1. passkey eller FIDO-sikkerhetsnøkkel
  2. autentiseringsapp med nummermatching
  3. tidsbasert engangskode fra autentiseringsapp
  4. SMS eller e-postkode når sterkere alternativer ikke finnes

CISA anbefaler phishing-resistent MFA . En engangskode kan fortsatt tastes inn på en falsk side, mens en korrekt implementert passkey er bundet til den legitime tjenesten.

MFA er ikke ferdig når første telefon er registrert:

  • håndhev metoden for alle relevante brukere
  • krev sterkere metode for administratorer og økonomi
  • registrer to kontrollerte autentikatorer der det er mulig
  • varsle ved ny faktor og endret gjenoppretting
  • fjern mistede og utrangerte enheter
  • test gjenoppretting uten å omgå identitetskontrollen

Den separate guiden om tofaktor og gjenoppretting går dypere i metodevalg.

Sikre gjenopprettingen

Den enkleste veien rundt sterk MFA kan være en svak passordreset.

Dokumenter:

  • hvem som kan be om reset
  • hvordan identiteten verifiseres uten den låste e-posten
  • hvilke telefonnumre og reserveadresser som er registrert
  • hvor gjenopprettingskoder og ekstranøkler oppbevares
  • hvem som varsles ved endring
  • hvordan support håndterer en kompromittert administrator
  • når gjenoppretting sist ble testet

Ikke la en privat e-postadresse eller telefon til en tidligere ansatt være virksomhetens eneste gjenopprettingsvei. Gjenopprettingskoder gir tilgang og skal beskyttes som passord.

Bruk navngitte kontoer, ikke delte passord

En rolleadresse som post@ eller faktura@ kan være nyttig. Problemet oppstår når flere deler samme passord og MFA.

Bruk heller:

  • personlige innlogginger med tilgang til en delt postkasse
  • delegering med minste nødvendige rettighet
  • distribusjonsgruppe når flere bare skal motta
  • alias når adressen skal leveres til én eksisterende konto

Da kan virksomheten avslutte én bruker, håndheve MFA per person og undersøke hvem som gjorde en endring. Sammenlign alias, gruppe og delt postkasse før dere oppretter enda en delt konto.

Onboarding, rollebytte og avslutning

Når en bruker starter

  1. Opprett en navngitt bedriftskonto.
  2. Gi bare nødvendige roller og postkasser.
  3. Registrer MFA og gjenoppretting under kontrollert identitetskontroll.
  4. Lær brukeren å rapportere uventede innloggingsforespørsler.
  5. Dokumenter eier, godkjenner og dato for ny tilgang.

Når ansvar endres

Gjennomgå roller, grupper, delegering, delte hvelv og aktive apper. Ikke legg bare ny tilgang oppå den gamle.

Når en bruker slutter

  1. Avtal sperretidspunkt med ansvarlig leder.
  2. Deaktiver innlogging og tilbakekall økter og tokens.
  3. Fjern MFA, app-passord, delegering og gruppemedlemskap.
  4. Overfør nødvendig virksomhetsinnhold etter en dokumentert prosess.
  5. Roter bare delte hemmeligheter personen faktisk kunne bruke.
  6. Kontroller videresending, innboksregler og nylige administratorendringer.
  7. Sett eventuell autosvar eller tidsbegrenset mottaksrutine etter virksomhetens behov.
  8. Slett eller avslutt postkassen når formål og plikter ikke lenger krever den.

En tidligere ansatts postkasse skal ikke bli en varig felleskonto. Les guiden om e-postarkiv og innsyn før tilgang eller innhold overføres.

En policy som kan kopieres

Alle brukere skal ha personlige kontoer. Passord skal være unike og lagres i godkjent passordmanager. Et passord som er eneste faktor skal ha minst 15 tegn. Tjenester skal tillate lange passord, autofyll og innliming. Kjente og lekkede passord skal avvises. Periodisk bytte og tvungne tegnmønstre brukes ikke uten særskilt behov. Sterkeste tilgjengelige MFA skal håndheves, med phishing-resistent metode for privilegerte brukere der plattformen støtter det. Gjenoppretting, tilgangsgjennomgang og avslutning skal ha navngitt eier og dokumentert test.

Tilpass teksten til systemenes faktiske støtte og virksomhetens risikovurdering. En policy som ikke kan håndheves eller måles, gir liten kontroll.

Kontroller hvert kvartal

KontrollDokumentasjon
brukere uten håndhevet MFAnavn, unntak, kompenserende tiltak og frist
privilegerte brukererolle, godkjenner og MFA-metode
delte passordeier og plan for utfasing
ukjente gjenopprettingsmetoderfjernet eller godkjent med dato
gamle økter, tokens og app-passordeier, siste bruk og utløp
passord funnet i lekkasjevarselberørte kontoer og respons
avsluttede ansattesperretid, overføring og sluttkontroll
test av gjenopprettingdato, deltakere, resultat og tiltak

Hva må avklares med e-postleverandøren?

Vymos publiserte e-postplaner oppgir spam- og virusfilter, webmail og klienttilgang. De lover ikke bestemte MFA-metoder, passkeys, sentral passordpolicy, økttilbakekalling eller detaljerte sikkerhetslogger. Ikke bestill ut fra en antakelse om at slike funksjoner følger med.

Har virksomheten konkrete sikkerhetskrav, send kravlisten før bestilling . Oppgi ønsket MFA-metode, antall administratorer, klienter, behov for gjenoppretting og krav til logger. Ikke send passord, gjenopprettingskoder eller aktive tokens i kontaktskjemaet.

Vil bedriften bruke e-post på eget domene?

Se lagring, funksjoner og pris per konto før dere bestiller.