Stöd för regelefterlevnad
Merula ger team löpande tekniskt underlag för de domänkontroller de är beroende av: DNS, TLS-certifikat, e-postautentisering, säkerhet i e-posttransporten, HTTP-huvuden, tillgänglighet, webbhygien, domänens livscykel och routning. Den här sidan förklarar hur iakttagelserna förhåller sig till erkända standarder, säkerhetsramverk och vägledningar – och var gränsen går.
Merula certifierar inte juridisk regelefterlevnad. Tjänsten övervakar kontinuerligt externt synliga tekniska kontroller som ofta stöder cyberhygien, revisionsberedskap, kundförtroende och NIS2-relaterad riskhantering. Genomgående betyder en mappning att Merula tillhandahåller tekniskt underlag som kan stödja en kontroll – aldrig en certifiering eller ett påstående om full regelefterlevnad.
OWASP Secure Headers
Kontrollen av HTTP-huvuden är i linje med den rekommenderade baslinjen i OWASP Secure Headers Project. Varje iakttagelse motsvarar en specifik rekommendation: saknad HSTS, saknad X-Content-Type-Options, saknat skydd mot inramning (X-Frame-Options eller CSP frame-ancestors), huvuden som avslöjar versionsnummer (Server, X-Powered-By, X-AspNet-Version) samt säkerhetsflaggor i Set-Cookie.
OWASP Top 10:2025
OWASP Top 10 är en katalog för riskmedvetenhet, inte ett regelverk att följa – därför är det här mappningar av riskrelevans, inte påståenden om överensstämmelse. Vi hänvisar till 2025 års utgåva. Bara ett fåtal kategorier har signaler som går att observera utifrån och som en domänövervakare verkligen kan belägga från utsidan av applikationen; resten kräver åtkomst på kodnivå, inloggad åtkomst eller åtkomst till applikationens inre, vilket vi inte har.
Observera: i 2025 års utgåva flyttades Security Misconfiguration upp från A05 (år 2021) till A02 – den näst mest kritiska kategorin enligt konsensus. Det är den kategori som Merulas iakttagelser om HTTP-huvuden, e-postautentisering och transport oftast hör till.
Mappningen görs på nivån av enskilda iakttagelser: en kontroll bidrar till en kategori bara när den visar den aktuella svagheten, inte per automatik. Listorna nedan anger de kontroller vars iakttagelser kan kopplas till respektive kategori.
- A02:2025 Security Misconfiguration – HTTP-säkerhetshuvuden, SPF, DKIM, DMARC, STARTTLS, MTA-STS, TLS-RPT, DANE, CORS-policy.
- A04:2025 Cryptographic Failures – TLS-certifikat (kedja, giltighetstid, värdnamn), härdning av protokoll och chiffer, DNSSEC, CAA-poster, tillämpning av HSTS.
- A01:2025 Broken Access Control (delvis) – iakttagelser om felkonfigurerad CORS och validering av SameSite för cookies (CWE-1275).
- A07:2025 Authentication Failures (begränsad extern signal) – validering av värdnamn och kedja i TLS-certifikatet där det påverkar serverns identitet. Merula bedömer inte användarautentisering, sessioner, identitetsleverantörer eller kontoskydd.
- A03, A05, A06, A08, A09, A10 – rör applikationens inre och ligger utanför vad en extern övervakare kan bedöma.
CWE:er som de här externa kontrollerna kan visa, per kategori:
- A02:2025 – CWE-5, CWE-614, CWE-942, CWE-1004 (samt CWE-16 generellt)
- A04:2025 – CWE-296, CWE-319, CWE-324, CWE-326, CWE-327, CWE-523, CWE-757 (7 av 32)
- A01:2025 – CWE-1275 SameSite, samt CORS, som överlappar med A02
- A07:2025 – CWE-295, CWE-297, CWE-298, CWE-299 (certifikatvalidering)
De här CWE-hänvisningarna beskriver de svagheter, observerbara utifrån, som Merula kan visa i dag. De är hänvisningar på iakttagelsenivå, inte ett påstående om full täckning av någon kategori eller CWE.
EU:s NIS2-direktiv – artikel 21.2
NIS2 kräver att väsentliga och viktiga entiteter vidtar lämpliga och proportionella åtgärder för att hantera cybersäkerhetsrisker. Merula avgör inte om du omfattas eller om du uppfyller kraven, men flera av temana i artikel 21.2 kan stödjas av externt tekniskt underlag från det offentliga domänlagret:
- (b) Incidenthantering – upptäckt av ändringshändelser, ändringsloggen per domän, leverans av larm.
- (c) Kontinuitet i verksamheten (begränsat) – övervakningen av när domänregistreringen löper ut belägger bara den del som gäller domänens tillgänglighet; säkerhetskopiering, katastrofåterställning och krishantering ligger utanför.
- (g) Rutiner för cyberhygien – DNS, certifikat, e-postautentisering, transportsäkerhet och HTTP-huvuden. En stor del av Merulas övervakning stöder det här temat.
- (h) Strategier för kryptografi och kryptering – utvärdering av TLS-protokoll och chiffer, STARTTLS, MTA-STS, TLS-RPT, DANE; e-postautentisering (SPF, DKIM, DMARC) hör till (g) ovan, som en cyberhygienkontroll.
- (e) Hantering och offentliggörande av sårbarheter (begränsat) – kontrollen av security.txt belägger en publicerad kanal för att rapportera sårbarheter; säkert förvärv, säker utveckling och säkert underhåll ligger utanför.
Det här täcker Merula inte under NIS2:
- (a) Riskanalys och strategier för informationssystemens säkerhet
- (d) Säkerhet i leveranskedjan
- (e) Säkert förvärv, säker utveckling och säkert underhåll – utom den publicerade kanalen för att rapportera sårbarheter, som security.txt belägger
- (f) Strategier för att bedöma hur effektiva åtgärderna är
- (i) Personalsäkerhet, åtkomstkontroll, hantering av tillgångar
- (j) Multifaktorautentisering och säkrad intern röst-, video- och textkommunikation samt nödkommunikation – en bestämmelse om interna kontroller som Merula inte kan observera utifrån
Merula ger löpande externt underlag för utvalda tekniska kontroller som hör till delarna om cyberhygien och kryptografi i artikel 21.2 i NIS2 – närmare bestämt (g), (h), upptäcktsdelen av (b), (c) genom övervakningen av när domänregistreringen löper ut, och kanalen för sårbarhetsrapportering i (e) genom security.txt.
Erkänd säkerhetsvägledning
Merulas kontroller av e-postautentisering och e-posttransport bygger på allmänt använda internetstandarder, och skälen till att övervaka dem löpande formuleras av erkända säkerhetsmyndigheter. Brittiska National Cyber Security Centre rekommenderar i sin vägledning Email security and anti-spoofing att organisationer inför SPF, DKIM och DMARC för att minska domänförfalskning, för en DMARC-policy mot tvingande läge i etapper – och följer rapporterna innan de skärper den – samt skyddar e-post under överföring med TLS. Det är samma kontroller som Merula övervakar och samma stegvisa väg som Merula hjälper dig att följa.
Referens: NCSC (Storbritannien) – Email security and anti-spoofing. Storbritanniens National Cyber Security Centre, vägledningen Email security and anti-spoofing.
Den europeiska hotbilden
ENISA:s Threat Landscape 2025 är en hotcentrerad analys av incidenter i EU – det externt dokumenterade skälet till att kontinuerlig domänhygien är värd uppmärksamheten. Den förstärker argumenten för kontinuerlig insyn: mönstret av överlappande, ihållande kampanjer som rapporten beskriver är precis det som gör kontroller vid enskilda tillfällen otillräckliga.
En iakttagelse från Merula är tekniskt underlag om det offentliga lagret av dina domäner – det som går att observera utifrån, och hur det har förändrats över tid.
Referens: ENISA Threat Landscape 2025 (på engelska) – referens för hotbilden. ENISA, Threat Landscape 2025 (oktober 2025) – en hotcentrerad analys av omkring 4 875 incidenter i EU, juli 2024 – juni 2025.
Standarder och RFC:er
Varje kontroll vilar på namngivna standarder, specifikationer eller erkänd säkerhetsvägledning. Vi undviker vaga formuleringar om ”bästa praxis” där det finns en mer precis hänvisning. Chipraden på varje kontroll i din instrumentpanel visar vilka standarder kontrollen ger underlag för.
IETF (RFC)
- DNS-uppslag och riktighet – RFC 1034, 1035, 2181, 2182, 3596, 4033–4035 (DNSSEC), 8659 (CAA)
- TLS för HTTPS – RFC 5246 (1.2), 8446 (1.3), 8996 (utfasning av 1.0/1.1), 9525 (modern validering av värdnamn), samt 7465 / 7457 / 8447 för chifferhygien
- E-postautentisering – RFC 7208 (SPF), 6376 (DKIM), 7489 (DMARC)
- Transportsäkerhet för SMTP – RFC 3207 (STARTTLS), 5321 (SMTP), 8461 (MTA-STS), 8460 (TLS-RPT), 6698 / 7671 / 7672 (DANE / TLSA)
- HTTP och huvuden – RFC 9110, 9112 (HTTP-semantik och meddelandeformat), 6797 (HSTS), 6265bis (säkerhetsflaggor för cookies)
- Webbhygien – RFC 9309 (robots.txt), RFC 9116 (security.txt)
Webbplattformen (W3C / WHATWG)
Moderna huvuden för webbläsarplattformen standardiseras inte inom IETF. Kontrollen av HTTP-säkerhetshuvuden omfattar specifikationerna från W3C och WHATWG: CSP Level 3, Cross-Origin-Opener-Policy, COEP, CORP, Referrer Policy, Permissions Policy och Fetch (CORS). Den rekommenderade baslinje vi följer är OWASP Secure Headers Project.
Branschbaslinjer
- Mozilla SSL Configuration Generator (baslinjen Intermediate) – förankrar listan över chiffermönster i vår utvärdering av TLS-härdning. Uppdateras kvartalsvis.
- NIST SP 800-52 Rev. 2 – den amerikanska federala förvaltningens riktlinje för TLS-konfiguration. Relevant för kunder med fokus på USA och för EU-dotterbolag som gör affärer i USA.
- CIS Benchmarks (NGINX, Apache, generisk webbserver) – listor för härdning av servrar. Våra kontroller av HTTP-huvuden och TLS täcker den delmängd som går att observera utifrån.
- sitemaps.org – strukturen för XML-webbplatskartor (inte en RFC, men de facto-standarden).
Löpande underlag över tid
Varje kontroll körs i en takt som motsvarar hur snabbt dess signal förändras: de flesta varje timme för varje aktiverad domän, SMTP-transportkontrollerna (STARTTLS, DANE) var sjätte timme, kontrollerna av domänregistret och registrarlåset dagligen och ursprungsvalideringen av rutter (RPKI) veckovis – inom de gränser för anslutningar, register och externa källor som var och en har att förhålla sig till. Varje resultat sparas; varje statusövergång skriver en ändringshändelse. Revisionsspåret finns per standard, inte bara per kontroll – du kan besvara ”när slutade vår tillämpning av RFC 8461 att fungera?” med en specifik ändringshändelse, inte med en kriminalteknisk utredning.
Externa referenser och vidare läsning
Källorna nedan påverkar hur Merula är byggt och förklarar varför kontinuerlig hygien för domäner och e-postsäkerhet är värd uppmärksamheten – erkända, oberoende referenser från standardiseringsorgan, nationella säkerhetsmyndigheter och krav i e-postens ekosystem.
- Internetstandarder (IETF / RFC) – protokollspecifikationerna bakom varje kontroll, förtecknade ovan: DNS och DNSSEC, TLS, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, DANE/TLSA, CAA, HSTS, robots.txt och security.txt. Merulas kontroller bygger på dessa allmänt antagna standarder snarare än på egenkonstruerade regler.
- NCSC (Storbritannien) – Email security and anti-spoofing – praktisk vägledning från en nationell cybersäkerhetsmyndighet om att införa SPF, DKIM och DMARC, att gå över till en tvingande DMARC-policy i etapper och att skydda e-post under överföring. NCSC: Email security and anti-spoofing (på engelska) ↗
- Nationella cybersäkerhetsmyndigheter i Europa – flera nationella myndigheter publicerar vägledning som pekar åt samma håll som standarderna ovan, särskilt när det gäller e-postautentisering, DNSSEC och säker transport. Tyska BSI beskriver e-postautentisering (SPF, DKIM, DMARC) och säker transport (STARTTLS, DANE, MTA-STS) i sina tekniska riktlinjer TR-03182 och TR-03108; nederländska NCSC, franska ANSSI, danska CFCS, finska NCSC-FI (Traficom) och spanska INCIBE publicerar motsvarande vägledning om e-postautentisering, DNSSEC och transportsäkerhet. I vissa jurisdiktioner har förväntningarna på e-postautentisering dessutom gått från vägledning till rättsliga eller sektorsspecifika krav för vissa leverantörer eller offentliga organ. De kontroller som Merula övervakar är de som dessa erkända myndigheter rekommenderar. BSI TR-03182 (på engelska) ↗ · NCSC (NL, på nederländska) ↗
- ENISA – europeisk bakgrund om cybersäkerhet: Threat Landscape 2025 (varför fortlöpande kampanjer som flyter samman gör löpande hygien viktig) och rapporten om små och medelstora företag, som beskriver cybersäkerhet som ett fortlöpande och konsekvent arbete. ENISA Threat Landscape 2025 (på engelska) ↗
- OWASP – Top 10:2025 och Secure Headers Project, mappade per kontroll i våra ramverksmappningar och sammanfattade ovan. OWASP Top 10 (på engelska) ↗
- NIST – Cybersecurity Framework 2.0, SP 800-53 Rev. 5 och SP 800-177 (Trustworthy Email), som vi hänvisar till för deras begrepp kring e-postsäkerhet och konfiguration och som är mappade per kontroll i våra ramverksmappningar.
- Avsändarkrav från e-postleverantörer – de autentiseringsregler för storskaliga avsändare som stora e-postleverantörer har infört (Gmail och Yahoo från februari 2024, Microsoft Outlook från maj 2025) gör korrekt SPF, DKIM och DMARC allt viktigare för leveransbarhet och förtroende, inte bara för säkerheten. Det är krav i ekosystemet som ställs av de mottagande e-postsystemen; de daterade fakta förklaras på sidan för småföretag.
NIS2 föreskriver inte en viss DMARC-konfiguration för varje organisation, men direktivet höjer förväntningarna på hantering av cybersäkerhetsrisker, styrning och effektiva kontroller – Merula stöder en konkret del av det, som går att observera utifrån. Den detaljerade NIS2-mappningen finns tidigare på den här sidan; de fullständiga, automatiskt genererade tabellerna finns i ramverksmappningarna.
Var Merulas data finns – lagringsplats kontra suveränitet
Merula byggs och drivs enligt svensk lag av ett team i Stockholm, som en del av Adspace Nordic AB. Vår infrastruktur körs i AWS i Stockholmsregionen, med säkerhetskopior i samma region.
Det ger dig datalagring inom EU (EU data residency): kunduppgifter, kontrollhistorik, metadata om larm och DMARC-rapporter finns fysiskt i AWS-regioner inom EU. Vi replikerar inte till regioner utanför EU, och vi överför inte data till personuppgiftsbiträden utanför EES utom där det är avtalsmässigt nödvändigt (Stripe för fakturering).
Det ger dig inte full datasuveränitet. AWS är en leverantör med huvudkontor i USA. Enligt amerikansk lag, bland annat CLOUD Act, kan amerikanska myndigheter begära åtkomst till data som innehas av amerikanska leverantörer även när datan lagras utanför USA. Separata amerikanska befogenheter för underrättelseinhämtning, till exempel enligt Executive Order 12333, ingår i det bredare rättsliga sammanhang som beaktas i bedömningar av överföringsrisker inom EU. Schrems II-domen (EU-domstolen, C-311/18, 2020) och ramverket för dataskydd mellan EU och USA (EU–US Data Privacy Framework) hör till det rättsliga landskapet. Ramverket förändrar bedömningen av överföringsrisken men tar inte bort behovet för kunder med strikta krav på suveränitet att göra en egen bedömning.
Vad det betyder i praktiken:
- För det användningsfall som Merula riktar sig till – kommersiell övervakning för små och medelstora företag – är drift i EU-regioner hos AWS en vanlig och pragmatisk arkitektur. De flesta små och medelstora företag och byråer i EU kör redan på AWS, GCP eller Azure; den data som Merula lagrar är inte känsligare än det de redan har hos samma leverantörer.
- För försvar, offentlig förvaltning, operatörer av reglerad samhällsviktig infrastruktur eller organisationer som omfattas av särskilda krav på suveränitet – där räcker det kanske inte med datalagring inom EU hos AWS. Merula riktar sig för närvarande inte till det segmentet; vi kommer att presentera en variant i ett suveränt moln om och när det blir kommersiellt rimligt att driva en sådan.
Vi säger det rakt ut, så att den som överväger att bli kund kan göra bedömningen med de faktiska förhållandena framför sig.
Den strukturerade matrisen
Den strukturerade matrisen, kontroll för kontroll, finns under Standarder och ramverksmappningar.